New macro: NS_INLINE_DECL_PURE_VIRTUAL_REFCOUNTING

[Kartikaya Gupta]

Just a heads-up that I pushed bug 1312319 which adds a new
NS_INLINE_DECL_PURE_VIRTUAL_REFCOUNTING macro to nsISupportsImpl.h.
This macro just defines pure-virtual AddRef/Release functions. It's
intended for use if you're creating a non-nsISupports interface where
you want the implementing classes to be refcounted. There were already
a lot of classes in the tree that were doing this and I updated them
to use the macro. Going forward please use the macro instead of
manually adding AddRef/Release pure-virtual functions to your
interfaces.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: Merging Quantum Render into mozilla-central

[Kartikaya Gupta]

(Explicitly forwarding to dev-tech-gfx and dev-platform, since
apparently bcc'ing lists gets messages stuck in moderation. Please
reply on dev-tree-management. Sorry for my mail-fail!)


-- Forwarded message --
From: Kartikaya Gupta 
Date: Mon, Jan 30, 2017 at 2:22 PM
Subject: Merging Quantum Render into mozilla-central
To: dev-tree-managem...@lists.mozilla.org


(bcc: dev-platform, dev-tech-gfx. Please keep discussion on dev-tree-management)

Work for the Quantum Render ("QR") project has been happening on the
graphics branch [1]. We've been doing regular merges from m-c to the
graphics branch, but the merge conflicts have slowly been getting more
complex as the two trees diverge. If we could merge graphics back to
m-c periodically it would help reduce this burden. I'd like to get
sheriffs to sign off on this, and give anybody else a chance to
comment as well.

What I would like to do is merge the changes from the graphics branch
back into m-c, but continue to keep the graphics branch as a "working
branch" for the QR project. We would continue doing daily merges from
m-c to the graphics branch, but only merge back from graphics to m-c
occasionally (I'm thinking around once a week or so). The graphics
branch would remain sheriffed by the graphics team.

As part of this, I would like to enable QR build jobs (which are
normal linux64/osx64/win64 builds with --enable-webrender in the
mozconfig) as tier-1, and linux64 QR test jobs as tier-2. I don't
expect that having the builds tier-1 would be a burden on platform
developers, as almost all of the new c++ code is compiled regardless
of the --enable-webrender flag, so developers will catch compile
errors with their usual workflow. Tests being tier-2 seems like an
acceptable compromise, as it doesn't block platform developers but
also gives us an early warning of changes that potentially affect QR.
In practice, most test failures we've experienced are simply new
reftests that need to be annotated with fails-if(webrender).

As QR builds would be tier-1, they would need to run on all
integration branches (including m-i and autoland), but I think QR test
jobs could be limited to running on m-c, to reduce the load on our
infra. Right now there's not a lot of QR test jobs anyway but we're
actively greening up more test suites and getting them running on the
QR builds.

If you're interested in more details on how we would go about doing
the merge, please see [2]. Any comments or suggestions are welcome.

Cheers,
kats

[1] https://hg.mozilla.org/projects/graphics
[2] 
https://groups.google.com/d/msg/mozilla.dev.tech.gfx/Foxlm-c-Md8/y6khtK1CCwAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Quantum Render builds now on m-c

[Kartikaya Gupta]

(cross-posted to dev-platform and dev-tech-gfx)

This is just a heads up that earlier today we merged the graphics
branch to m-c, so Quantum Render builds can now be done on central if
you put --enable-webrender in your mozconfig.

We will be running a limited set of builds (linux64 only) and tests
(reftests, jsreftests, crashtests) on mozilla-central (not
inbound/autoland/other trees) as tier-2. The graphics branch will
continue to run all of the QR builds and tests that we have working so
far, so as to ensure we don't regress anything. The bulk of the
development will continue on the graphics branch, with period merges
back and forth, so that we don't need to run the full slate of QR
tests on all inbound/autoland pushes.

If you run into any issues or have questions feel free to contact me directly.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should cheddar-generated headers be checked in?

[Kartikaya Gupta]

On Mon, Feb 27, 2017 at 1:57 PM, Henri Sivonen  wrote:
> Now that the build.rs in commented out in the crates.io crate and the
> generated header is shipped in the crates.io crate:
> Considering that editing the vendored crates is not allowed, so I
> can't put moz.build files on the path to the headers, what's the
> appropriate way to make the m-c build system pick up headers from
> third_party/rust/encoding_c/include?
>

I haven't tried this myself, but you should be able to reference the
include from any moz.build file. e.g.

# in foo/bar/moz.build
EXPORTS += [
  ...
  "../../third_party/rust/encoding_c/include/MyHeader.h"
 ...
]

Does that not work?

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

[Kartikaya Gupta]

It looks like it's just the Linux builds that are no longer there. I'm
guessing this has to do with them being on TaskCluster rather than
BuildBot.

On Mon, Mar 6, 2017 at 4:23 PM, Boris Zbarsky  wrote:
> On 3/6/17 4:17 PM, Eric Rahm wrote:
>>
>> I'm unaware of a bug for this decision, but https://archive.mozilla.org
>> stopped adding tinderbox builds back on January 18th.
>
>
> I'm unaware of a discussion of this at all.  Why did this happen?
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All the processes

[Kartikaya Gupta]

On Mon, Mar 6, 2017 at 7:08 PM, Eric Rahm  wrote:
> I assume WebRenderer will have it's own process, but maybe that just gets
> lumped in with the GPU process.

WebRender will live in the GPU process, if there is one. The UI
process otherwise.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Kartikaya Gupta]

I've been reading this thread with much sadness, but refraining from
commenting because I have nothing good to say. But I feel like I
should probably comment regardless. What makes me sad is all the
developers in this thread trying to push back against disabling of
clearly problematic tests, asking for things like tracking bugs and
needinfos, when the reality is that the developers just don't have the
time to deal with new bugs or needinfos. After all, the test was
disabled only *after* bugs were filed and people were needinfo'd with
no response. In my experience, Joel and the sheriffing team put in a
lot of hard work starring these things and filing bugs, only to have a
lot of that work ignored. Except of course when it comes to threads
like this, when everybody has an opinion, mostly asking for even more
of them. (I am aware that many developers do actually investigate and
fix intermittents, and that set of developers is orthogonal of the set
of developers pushing back in this thread, but it still disheartens
me).

I think we have a structural problem where developers are insulated
from the actual fallout of bad tests. They're not the ones who have to
deal with starring failures. For a while now I've been doing this work
on the graphics branch, and it's not fun at all. There are so many
failures (and variations of failures) on a typical push that it
becomes very easy to "zone out" and just pick a sort-of-matches
existing failure and star a new failure with it. This leads to
mis-starring of stuff and missing new legitimate failures. I'm sure
the sheriffs do a better job than I do, but even so the trend is clear
to me: more unsolved intermittents will result in more bad data across
the board, and more missed legitimate failures. (Think of it like
fixing warnings in code - if you already have reams of warnings you're
easily going to miss a new one being added).

Sure, there's tooling we can improve. And sure, we can tweak the way
we process these things. And there are some good suggestions upthread
that we should do. But I feel fundamentally the problem is that
developers have no real incentive (except for "pride") to fix
intermittents. Even disabling tests is not really an incentive, as
there is no negative effect to the developer when it happens. The
naive solution to aligning incentives is to make more developers
responsible for starring failures. I believe this was done in the
past, but I don't really want to go back there. For one thing, we
would lose a valuable across-the-board view of common types of similar
errors, and sheriffs do a lot of non-obvious starring as well
(sometimes the relevant error message doesn't show up in the TH view)
or recall bugs from memory which is hard for other people to do.

Another potential solution is block developers until they fix their
tests. This is actually not as crazy as it sounds. After all, when
landing code, reviewers can (and should) block developers from landing
until they have tests that go with the code. So why is it that the bar
is lowered later, and the test is allowed to be disabled without
backing out or disabling the corresponding code? (Rhetorical
question). It's not easy to back out or disable code, but it's much
easier to prevent a developer from landing new code if they have a
backlog of intermittents or disabled tests. But again, this is also a
bad solution for various reasons.

I've been around long enough to realize that there's no real good
solution here. And that makes me sad. But I also do want to really
thank Joel and the sheriffs and anybody else who has to deal with
pointy end of this problem for doing the great job that they do, given
the circumstances. And I'd like to encourage developers to try and
take more responsibility for intermittent failures, even in the
absence of adequate tooling and STR and all that other good stuff. At
the very least respond to your needinfos.

Cheers,
kats


On Wed, Mar 8, 2017 at 5:18 AM,   wrote:
> On Tuesday, March 7, 2017 at 11:45:38 PM UTC-5, Chris Pearce wrote:
>> I recommend that instead of classifying intermittents as tests which fail > 
>> 30 times per week, to instead classify tests that fail more than some 
>> threshold percent as intermittent. Otherwise on a week with lots of 
>> checkins, a test which isn't actually a problem could clear the threshold 
>> and cause unnecessary work for orange triage people and developers alike.
>>
>> The currently published threshold is 8%:
>>
>> https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy#Identifying_problematic_tests
>>
>> 8% seems reasonable to me.
>>
>> Also, whenever a test is disabled, not only should a bug be filed, but 
>> please _please_ need-info the test owner or at least someone on the affected 
>> team.
>>
>> If a test for a feature is disabled without the maintainer of that feature 
>> knowing, then we are flying blind and we are putting the quality of our 
>> product at risk.
>>
>>
>> cpearce.
>>
>
> Thanks cpearce for the concern h

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Kartikaya Gupta]

On Wed, Mar 8, 2017 at 4:01 PM,   wrote:
> In the past I have not always been made aware when my tests were disabled, 
> which has lead to me feeling jaded.

We have a process (in theory) that ensures the relevant people get
notified of tests. The process involves these steps:
1) There is a moz.build file somewhere in the tree which covers the
tests in question and specifies a BUG_COMPONENT for it
2) If a test starts failing intermittently, a bug is filed in the
aforementioned component
3) The component is monitored/triaged regularly by the module owner or team
4) Whoever triages the bug notifies the individual owner if they're
not already on the bug

So if for some reason anybody feels like they were not notified when
their tests are being disabled, they should find the link the above
chain where things broke down (e.g. no BUG_COMPONENT for a test, bug
filed in a component other than BUG_COMPONENT, nobody triaging new
bugs, etc.) and do something about it.

>
>> and it would be reasonable to expect a fix.
>
> I think it's unreasonable to assume that developers can drop whatever they're 
> doing and turn around a fix in a two weeks, given how long these things often 
> take to fix, and given that developers often have a pre-existing list of 
> other high priority stuff to work on.
>

In my experience it's not so much that a fix is needed in two weeks,
it's that you need to put in a good-faith effort to respond and start
investigation. Oftentimes it legitimately takes longer than two weeks
to fix intermittents, but I've never had a scenario where I asked for
more time and was denied that.

>
> I think:
> * Acceptable failure rates as expressed as an absolute number aren't 
> meaningful; we should be expressing acceptable rates as a percentage.

On the one hand, I agree with your rationale here. On the other hand,
the people who have to deal with the problem (sheriffs) have to deal
with it linearly. i.e. 60 failures is twice as much work for them than
30 failures, regardless of the number of pushes. So from their
perspective an absolute number does make sense. I don't have a strong
opinion on this either way, just pointing out the other side.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Kartikaya Gupta]

On Wed, Mar 8, 2017 at 6:02 PM, L. David Baron  wrote:
> As of 5 days ago, "Treeherder Bug Filer" was not using BUG_COMPONENT
> information.  I say this based on:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1344304
> being filed in Core :: Layout despite:
>   > $ ./mach file-info bugzilla-component 
> layout/style/test/test_compute_data_with_start_struct.html
>   > Core :: CSS Parsing and Computation
>   >   layout/style/test/test_compute_data_with_start_struct.html
>
> (I wish it did use BUG_COMPONENT!  That's the main reason I bothered
> to write good BUG_COMPONENT data for most of layout/*.)
>

Thanks for letting me know! I verified that indeed the bug filer
doesn't check the BUG_COMPONENT. I'll look into fixing that.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to build (but not enable) WebRender by default on some Nightly platforms

[Kartikaya Gupta]

(Cross-posted to dev-platform and dev-tech-gfx, please reply to dev-platform)

In the near future I'm planning to make a change so that WebRender
will be built (but not enabled) by default in most Nightly/local
builds [1]. This will allow anybody running a stock nightly to turn on
The QuantumRender Experience™ by flipping a pref [2] and restarting
the browser [3].

Because this change will build more rust code into libxul,
compilation/linking time may be negatively impacted. Developers will
still be able to explicitly disable building webrender by putting
`ac_add_options --disable-webrender` in their mozconfig.

Furthermore, explicitly putting `ac_add_options --enable-webrender`
into your mozconfig will enable the pref for you by default, so that
if you have been doing builds with this flag already and expecting QR
to be on by default, it will continue to do so.

Patches are in bug 1342450 and dependencies if you want to follow
along. If you run into problems with this, please file a bug and cc
me, or reply to this email.

Cheers,
kats

[1] Not yet on Android, or OS X automation builds on Buildbot
[2] The pref is gfx.webrender.enabled
[3] There are more conditions in play than just the pref, see
gfxPlatform::InitWebRenderConfig().
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Project Stockwell (reducing intermittents) - March 2017 update

[Kartikaya Gupta]

On Thu, Mar 9, 2017 at 10:31 AM, Kartikaya Gupta  wrote:
> On Wed, Mar 8, 2017 at 6:02 PM, L. David Baron  wrote:
>> As of 5 days ago, "Treeherder Bug Filer" was not using BUG_COMPONENT
>> information.  I say this based on:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1344304
>> being filed in Core :: Layout despite:
>>   > $ ./mach file-info bugzilla-component 
>> layout/style/test/test_compute_data_with_start_struct.html
>>   > Core :: CSS Parsing and Computation
>>   >   layout/style/test/test_compute_data_with_start_struct.html
>>
>> (I wish it did use BUG_COMPONENT!  That's the main reason I bothered
>> to write good BUG_COMPONENT data for most of layout/*.)
>>
>
> Thanks for letting me know! I verified that indeed the bug filer
> doesn't check the BUG_COMPONENT. I'll look into fixing that.

FYI it looks like this has since been fixed by Wes, in bug 1347764.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to build (but not enable) WebRender by default on some Nightly platforms

[Kartikaya Gupta]

Note that this landed on inbound yesterday and was merged to m-c this
morning. If you get strange build errors (bkelly already reported one
due to missing the glXGetCurrentContext symbol) it might be because of
this. Adding ac_add_options --disable-webrender to your mozconfig
should work around it, but please file a bug as well and mark it
blocking bug 1342450. Thanks!

On Mon, Mar 13, 2017 at 6:08 PM, Kartikaya Gupta  wrote:
> (Cross-posted to dev-platform and dev-tech-gfx, please reply to dev-platform)
>
> In the near future I'm planning to make a change so that WebRender
> will be built (but not enabled) by default in most Nightly/local
> builds [1]. This will allow anybody running a stock nightly to turn on
> The QuantumRender Experience™ by flipping a pref [2] and restarting
> the browser [3].
>
> Because this change will build more rust code into libxul,
> compilation/linking time may be negatively impacted. Developers will
> still be able to explicitly disable building webrender by putting
> `ac_add_options --disable-webrender` in their mozconfig.
>
> Furthermore, explicitly putting `ac_add_options --enable-webrender`
> into your mozconfig will enable the pref for you by default, so that
> if you have been doing builds with this flag already and expecting QR
> to be on by default, it will continue to do so.
>
> Patches are in bug 1342450 and dependencies if you want to follow
> along. If you run into problems with this, please file a bug and cc
> me, or reply to this email.
>
> Cheers,
> kats
>
> [1] Not yet on Android, or OS X automation builds on Buildbot
> [2] The pref is gfx.webrender.enabled
> [3] There are more conditions in play than just the pref, see
> gfxPlatform::InitWebRenderConfig().
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: git mirrors are not updating

[Kartikaya Gupta]

Just a heads-up that the git mirrors of m-c (e.g.
github.com/mozilla/gecko-dev and github.com/mozilla/gecko-projects)
are not updating, and are stuck on a changeset from sometime on March
24. Bug 1350696 is open for the investigation.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Editing vendored crates take #2

[Kartikaya Gupta]

At one point the steps at
https://wiki.mozilla.org/Platform/GFX/Quantum_Render#Testing_third-party_rust_library_changes
were known to work. I don't know if they have since been broken.

On Fri, Apr 28, 2017 at 3:07 PM, Boris Zbarsky  wrote:
> On 4/28/17 1:05 PM, Josh Matthews wrote:
>>
>> Has anybody been able to make this work?
>
>
> I _think_ I made it work recently-ish, like so:
>
> 1)  Modify toolkit/library/rust/Cargo.toml with the relevant [replace] bit.
>
> 2)  Run "cargo vendor" and watch it fail because of something I never
> figured out.
>
> 3)  revert the changes "cargo vendor" made to third-party/rust (i.e.
> deleting the whole dir)
>
> As it happens, "cargo vendor" updated the Cargo.lock files in the right way
> before it failed out, so things worked.  Again, I _think_ that was the
> procedure.
>
> I'm not claiming this is in any way sane, btw.
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updating a particular vendored crate by minor version

[Kartikaya Gupta]

You can update a specific crate to a specific version like so:

cd toolkit/library/rust
cargo update -p encoding_rs --precise 
cd ../gtest/rust
cargo update -p encoding_rs --precise 
cd ../../../../
mach vendor rust


On Tue, May 2, 2017 at 4:38 AM, Henri Sivonen  wrote:
> I have toolkit/library/rust/shared/Cargo.toml depending on a crates.io
> crate encoding_c, which depends on encoding_rs.
>
> Then I update the minor version of encoding_rs on crates.io but don't
> update encoding_c.
>
> Now if I re-run ./mach vendor rust, nothing happens, because I didn't
> change the encoding_c dependency version in
> toolkit/library/rust/shared/Cargo.toml to force the dependencies to be
> unsatisfied.
>
> If, instead, I delete toolkit/library/rust/shared/Cargo.lock and then
> run ./mach vendor rust, I get minor version updates to all crates in
> the dependency graph that have changed since they were vendored.
>
> Other than manually merging lock files and unstaging unrelated crate
> changes, how do I scope the re-vendoring to encoding_rs only?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Making QuantumRender tier-1

[Kartikaya Gupta]

(cross-posted to dev-tech-gfx and dev-tree-management, please direct
replies to dev-platform)

I just landed a change on inbound (bug 1363344) that enables various
test jobs (reftests, jsreftests, crashtests, webgl mochitests, gpu
mochitests) on the Linux64 QuantumRender (aka "linux64-qr") platform
for autoland, inbound, and central. It also marks them as tier-1, so
breaking these will probably result in backout of the offending patch.
We are making this change for a couple of reasons:

1) we've had a number of cases recently where after merging a pile of
stuff from m-c over to the graphics branch, we got QR test bustage,
and it was painful to track down what caused it
2) this is a necessary step for QR work to migrate from the graphics
to using the regular integration branches, which is something we'd
like to do in the not-too-distant future

If you do cause breakage in QR jobs, you should be able to reproduce
it locally or on try as with regular tests. A "linux64-qr" build is
just a regular linux64 build with the gfx.webrender.enabled pref set
to true. (I plan to eliminate the actual build job in bug 1342488). On
try you can use a syntax like "try: -b o -p linux64-qr -u
all[linux64-qr]" to run all the available linux64-qr tests.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reftest "fuzzy" and "fuzzy-if" annotations now take ranges

[Kartikaya Gupta]

This morning I pushed bug 1252361 to inbound, which modifies the
"fuzzy" and "fuzzy-if" reftest annotations to accept ranges in
addition to single values for the fuzziness parameters. If a single
value "x" is provided, it by default maps to the range "0..x", so it
preserves the existing semantics in reftest.list files.

However I would very strongly encourage people adding new reftests
with fuzz values to use ranges rather than single values, so that if
the actual fuzziness drops we catch it. If the actual pixel
differences are below the allowed range, the test will trigger an
UNEXPECTED-PASS result, so it should show up on TreeHerder as a
failure.

It would also be great to look at existing tests and reduce or tighten
the allowed fuzziness. There are a lot of tests that are currently
"overfuzzed" (i.e. that have larger-than-needed fuzzy values). Here is
an example try push [1] that shows tests that are marked as fuzzy but
don't need it because they have zero differences (on Linux/Android,
anyway). And this is only a subset of the overfuzzed tests.

A final thing to note is that the raw logs on TreeHerder will now also
print out the exact fuzziness along with the allowed range, so you can
easily see from any push what the state of fuzziness is. For example
in this log [2] you can find entries like this:
   REFTEST INFO | REFTEST fuzzy test (0, 0) <= (33, 192) <= (80, 1500)
which indicates that the *actual* differences in the test/ref were
(33,192) but the allowed range was (0..80, 0..1500). So in this case
the test is overfuzzed because it allows a difference of up to 1500
pixels but only 192 pixels are different (and likewise it allows any
rgb component to be different by up to 80, but the maximum encountered
difference was 33). This was a Linux64 log, and we'd want to check the
results for this test across all platforms, but it's possible this
range could be tightened.

See the commits on the bug for more documentation on the exact
semantics of the ranges.

Cheers,
kats

[1] 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=63d6def39a86e54db467a79fd9be71b5ca9be41b
[2] 
https://treeherder.mozilla.org/logviewer.html#?job_id=104071750&repo=mozilla-inbound
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for informing Developers and Sheriffs about new Testsuites

[Kartikaya Gupta]

This sounds good to me. What mailing lists should the intent email be
sent to? It might help to have a template somewhere as well.

On Wed, Jun 14, 2017 at 4:58 AM, Carsten Book  wrote:
> Hi,
>
> we had the case that a new testsuite was enabled and one test of that suite
> resulted in a new perma orange failure. Its a tier-2 testsuite but of
> course also tier 2 cause additional work for sheriffs.
>
> The Problem on new Testsuite is that Sheriffs are in a lot of cases not
> informed about that new testsuite (so we need to find out who to contact
> etc) and also it affects Developers because they might be confused why
> their try run is showing a orange result they don't even know of (and waste
> time in finding out if that test is red/orange because of their change).
>
> So i propose:
>
> People should email with an intent to implement when adding a new
> platform/suite, and that email should contain links to docs/wiki/... and
> the persons (in a super optimal case more than one just for timezone
> coverage if sheriffs have question) we can contact in case of questions.
>
> this would benefit in :
>
> 1) sheriffs will know who to speak to if it's failing or needs to be hidden
> - so we can assign bugs or even ping people directly on irc
> 2) developers know what this new test is when they break it on their try
> push and so save time and resources if the failure is known and sheriffs or
> others can point to a bug/newsgroup mail
> 3) discussions can be had about any overlap the new tests have with other
> suites or say deciding what platforms it should run on etc
>
> I guess this would help Sheriffs and Developers. I initially was thinking
> about about a changelog on treeherder for such changes but that have the
> disadvantage that this would not include all the information we need to
> contact someone etc
>
> I hope that this proposal make sense.
>
> Cheers,
> - Tomcat
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How are events passed between chrome and content?

[Kartikaya Gupta]

On Thu, Jun 15, 2017 at 4:16 PM, Jim Porter  wrote:
> From what I can tell, if I click inside a webpage, the event starts out
> in chrome and then propagates down into content. I assume there's some
> sort of magic happening in the message manager that pushes the event
> across process boundaries.

Not quite. For e10s, mouse events are sent across the process boundary
using the PBrowser ipdl protocol. On the parent side they go into
EventStateManager::DispatchCrossProcessEvent [1] which picks up the
TabParent and sends it over IPC to the TabChild. The TabChild then
dispatches it to the PuppetWidget in the content process.

> I'm working on a Firefox add-on for mouse gestures and as part of this I
> need to delay the opening of the context menu on Linux to occur on
> mouseup rather than mousedown. I do this by swallowing the original
> contextmenu event with .preventDefault()/.stopPropagation(). Then on
> mouseup, I synthesize my own contextmenu event. This works fine when
> clicking on something in chrome, but no context menu pops up if I click
> on something in content.

If you set the right flags on the event it should get through.
Presumably you're creating this event from JS - you want to make sure
that it creates a WidgetMouseEvent with eContextMenu message type. I
don't know if that can be done without using the DOMWindowUtils APIs.
Posting your code snippet for event creation might help.

[1] 
http://searchfox.org/mozilla-central/rev/20d16dadd336e0c6b97e3e19dc4ff907744b5734/dom/events/EventStateManager.cpp#1228
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bulk Closing Intermittents

[Kartikaya Gupta]

It might be a good idea to integrate this process with the
OrangeFactor Robot, to avoid race conditions like what happened on bug
1328486 (it was bulk-closed, and then a couple of hours later the OF
robot reported that there were two failures this week - but the bug
remained closed).

Cheers,
kats

On Fri, Jul 7, 2017 at 10:35 PM, Emma Humphries  wrote:
> As discussed earlier, Joel and I have kicked off a process to close
> intermittent test failures in Bugzilla.
>
> If a test associated with a bug does not fail in 21 days, we'll close the
> bug as RESOLVED:INCOMPLETE.
>
> The first batch of intermittent bugs to close has 5,130 tickets. I have a
> script to close these, but to close these without bug spam requires DBA
> intervention.
>
> I'd like to run the closures over the weekend but that's going to create a
> non-trivial amount of bug spam for some of you.
>
> There is a way to get rid of the bug spam!
>
> Every bug we close will have the keyword `bulk-close-intermittents` added
> to it.
>
> If you search for messages from `bugzilla-dae...@mozilla.org` containing
> `bulk-close-intermittents` you can isolate, review, and remove those
> messages.
>
> Thank you for your patience while we all work to get the noise out of
> Bugzilla so we can find the strong signals on what we must focus on to
> deliver Firefox 57 in November.
>
> -- Emma
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git mirror

[Kartikaya Gupta]

https://github.com/mozilla/gecko-dev is generally pretty up-to-date. It
should have a branch for ESR as well.

Cheers,
kats

On Jul 22, 2017 15:43, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> wrote:

Hi folks,


are there any official git mirrors (at least for the esr branches),
that are regularily updated ?

The repos is *really* huge - import really takes a long time (started
about 10hrs ago, still just not much over 10%). Github even gives up.
Even hg clone runs for hours.

I'm looking for an git repo, where I can do a (shallow) clone from,
that also receives updates from the hg master.


thx

-- 

mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Correct format specifier for size_t

[Kartikaya Gupta]

I filed bug 1384233 for removing the header and unnecessary defines.

On Tue, Jul 25, 2017 at 2:13 PM, Honza Bambas  wrote:
> Thanks!  OTOH, I think we no longer need it.  Since VS2015 (our minimal
> toolchain version on Win) supports %z modifier.  Only VS2013 and down only
> defines %I.
> -hb-
>
>
> On 7/25/17 7:03 PM, Botond Ballo wrote:
>>
>> We have a mozilla/SizePrintfMacros.h header which defines "PRIuSIZE"
>> for this purpose.
>>
>> Cheers,
>> Botond
>>
>> On Tue, Jul 25, 2017 at 12:43 PM, Honza Bambas 
>> wrote:
>>>
>>> In light of using PRxx formatting macros from inttypes.h, what is the
>>> right
>>> approach to printf size_t types (like our nsTArray::Length()) ?
>>>
>>> Not sure if to use "%zu" directly.
>>>
>>> Thanks.
>>> -hb-
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: pushing to try is broken right now

[Kartikaya Gupta]

Pushes to try appear to succeed, but the pushlog is somehow busted and
so TreeHerder won't pick them up and the csets on hg.m.o will show
"unknown" for push info. This is being tracked in
https://bugzil.la/1387407. I've closed the try tree for now since it's
not clear if these pushes will just get thrown away or what.

cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: pushing to try is broken right now

[Kartikaya Gupta]

gps did some magic and things seem to be working again. Pushes that
occurred previously are now showing up on try, so I've reopened the
tree.

On Fri, Aug 4, 2017 at 11:02 AM, Kartikaya Gupta  wrote:
> Pushes to try appear to succeed, but the pushlog is somehow busted and
> so TreeHerder won't pick them up and the csets on hg.m.o will show
> "unknown" for push info. This is being tracked in
> https://bugzil.la/1387407. I've closed the try tree for now since it's
> not clear if these pushes will just get thrown away or what.
>
> cheers,
> kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Heads-up: WebRender now requires HWA enabled

[Kartikaya Gupta]

TLDR: Once bug 1387764 merges to mozilla-central, anybody running with
WebRender enabled on Linux will need to force-enable hardware
acceleration (layers.acceleration.force-enabled=true) to keep
WebRender enabled.

Long version:
Previously the check for enabling WebRender ignored the status of
hardware acceleration availability, and so WR was getting enabled even
if HWA was disabled. This was not great because it could result in
using unstable GPUs and such. This is corrected by the patch in bug
1387764.

However, Linux has HWA disabled by default, so this means trying to
enable WR on Linux will not work by default. about:support should
indicate why, if this happens. To correct it, set
layers.acceleration.force-enabled to true on Linux, which will
force-enable HWA and allow WR to be enabled as well.

As a reminder, if you want to enable WR you can either set
gfx.webrender.enabled to true, or you can run with MOZ_WEBRENDER=1 in
your environment.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Debugging Firefox e10s with rr?

[Kartikaya Gupta]

rr works just fine with multiple processes. Once you have a recording
you can use `rr ps` to show all the process that were recorded and `rr
replay -p ` to attach to a particular process. You can combine -p
with -g as Cameron mentioned to jump to a particular point in a
particular process' lifetime.

On Tue, Aug 29, 2017 at 9:12 AM, Cameron McCormack  wrote:
> On Tue, Aug 29, 2017, at 08:58 PM, Emilio Cobos Álvarez wrote:
>> I didn't find any obvious docs in either the rr wiki[1] or MDN, so I
>> thought I'd ask before I actually need it.
>>
>> What is the best/easiest way to debug Firefox multi-process using rr?
>>
>> Right now I just disable e10s, but that's probably not a great long-term
>> solution...
>
> I do that too. :-)
>
> Mine is probably not the most efficient method, but most of the time I
> record with -M, and use output lines (either turning on logging, like
> RUST_LOG=debug, or adding printfs showing details of documents/elements)
> to orient myself when debugging.  Doing a "rr replay -g " for a
> particular output line will break in the process that printed out that
> line.  (I've never had to debug something under rr that involves the
> interaction between processes.)
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New minimum Rust version policy for Firefox

[Kartikaya Gupta]

Do we have a policy on CI coverage for vendored rust libraries? I'm
concerned for example that we depend on a number of third-party rust
libraries that don't do CI builds against rust stable and so it's
possible they might break. I discovered that webrender CI for example
is currently only building against 1.17.0 and nightly. I don't think
we've actually encountered breakage from this but just wondering.

in third_party/rust$ find . -name ".travis.yml" | xargs grep -l
"rust:" | xargs grep -L -- "stable"
./cfg-if/.travis.yml
./dtoa/.travis.yml
./itoa/.travis.yml
./mime/.travis.yml
./num/.travis.yml
./ordered-float/.travis.yml
./semver-0.1.20/.travis.yml
./synstructure/.travis.yml
./thread-id/.travis.yml
./unicode-width/.travis.yml
./unicode-xid/.travis.yml
./uuid/.travis.yml

Cheers,
kats

On Tue, Aug 1, 2017 at 2:58 PM, Bobby Holley  wrote:
> This is great - thanks Ralph!
>
> On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles  wrote:
>
>> We've formalized a new plan for when we update the minimum-required Rust
>> version for building Firefox. Starting later this week we'll require the
>> latest stable Rust two weeks after it is released.
>>
>> This means we'll start requiring Rust 1.19.0 August 3rd. If you compile
>> mozilla-central and haven't run './mach bootstrap' recently, I suggest
>> doing so now to update.
>>
>> I've posted a full schedule
>> 
>> of when the minimum version will change for m-c, and what version of Rust
>> will be required to build each Firefox release. These are expectations to
>> aid in planning; we may delay particular bumps if there are issues or a
>> code freeze, but the expectation is that we'll need to update our
>> development environments by those dates.
>>
>> We expect ESR releases will stay on the Rust version of the corresponding
>> stable release.
>>
>> This change is based on several meetings and discussions with contributors
>> over the last two months. Rust is evolving quickly, and those working on
>> Rust code need to know what release to target. Previously we updated the
>> target version every few releases, whenever someone argued there was a
>> sufficiently compelling feature. Negotiating that every time was
>> distracting. Having a planned schedule lets everyone coordinate their work.
>> Updating Rust regularly helps us iterate and improve the language,
>> participating in the incredible momentum of the Rust developer community.
>>
>> Waiting two weeks gives contributors some time to update their
>> environments. This is especially relevant to those who don't always have a
>> fast network connection, or work on tier-3 targets where using upstream
>> Rust packages isn't possible.
>>
>> This doesn't affect our policy for official Firefox builds, just developer
>> builds and downstream packagers. I've written up details of the policy
>> , along with
>> motivation and considered alternatives. Please read that before responding
>> if you have concerns. I'll update the page next week in response to any
>> persuasive arguments and move the minimum-version proposal to the current
>> policy section.
>>
>> Thanks for you time, and let me know if you have any questions.
>>
>> Ralph Giles
>>
>> ___
>> dev-builds mailing list
>> dev-bui...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-builds
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New minimum Rust version policy for Firefox

[Kartikaya Gupta]

There was a bit of discussion on the PR I submitted yesterday:
https://github.com/servo/webrender/pull/1644#discussion_r136424367 -
we decided to just manually bump it once in a while instead of making
it track `stable`.

On Thu, Aug 31, 2017 at 5:54 PM, Mike Hommey  wrote:
> On Thu, Aug 31, 2017 at 10:27:55AM -0500, Jack Moffitt wrote:
>> Specifically for webrender (and anything else under the servo org on
>> GitHub), you can just file a bug and assign to edunham and we'll fix
>> that up.
>>
>> jack.
>
> Note that for webrender specifically, it used to build against stable,
> but back then Firefox required 1.15 and a webrender change broke that.
> To avoid the problem again, I added 1.15.1 to .travis.yml, but there
> were concerns about the number of travis jobs that incurred, so I
> removed stable at the same time
> (https://github.com/servo/webrender/pull/1334). Later that minimum
> version was bumped to 1.17 when Firefox bumped its requirement, but
> hasn't been bumped since.
>
> Now that Firefox nightly kinda sorta follows stable, I guess using
> stable instead of a hardcoded version again makes sense.
>
> Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Canonical cinnabar repository

[Kartikaya Gupta]

This message was inspired by the `mach try` thread but is off-topic
there so I think deserves its own thread.

It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.

I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.

As an aside, I also think that the cinnabar workflow as it exists now
actually demotes git to more of a "second-class citizen".
Conceptually, if you're using gecko-dev, everything works exactly as a
git user would expect, and only when you need to push to official
mozilla hg repos do you need to overcome the vcs translation hurdle
(which things like moz-git-tools help with). However if you use
cinnabar the vcs translation is more woven into your everyday git
commands (e.g. git pull) and you need to be more consciously aware of
it. This makes it harder to use whatever your normal git workflow is,
which is why I claim it demotes git to second-class. It would be great
if we could come up with a way to avoid this but honestly since I
haven't used a cinnabar workflow for any significant period of time I
haven't given much thought as to how to go about doing this.

Discussion welcome!

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Kartikaya Gupta]

On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez  wrote:
> Having said that, I agree that it's worth enabling developers to clone a
> canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a
> while to experiment with ways of doing this.

That's great, thanks. If we can do something like this but (a) with
all the pre-mercurial history, and (b) include integration/release
branches, that would basically be exactly what I want as a canonical
upstream cinnabar repo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Kartikaya Gupta]

So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.

And we have mozilla/gecko on github which is a cinnabar mirror.
However this mirror is not "officially" supported (i.e. it's updated
by Myk but not by Release Operations). It also doesn't seem to have
branches for inbound/autoland.

So it seems to me that the next step is to have the operations team
take over ownership of the mozilla/gecko mirror. dhouse, do you know
what the process would be for that? I'm guessing this just involves
running a cinnabar conversion and pushing to github on a cron job, but
Myk can provide more details, assuming he agrees this is what we want
to do. Eventually once cinnabar supports storing metadata in the repo
we'll want that pushed to the github repo as well.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Pulsebot in #developers

[Kartikaya Gupta]

+1. I also find myself less likely to read the backscroll because of the
high volume of pulsebot messages.

Thanks for bringing this up!

On Nov 4, 2017 07:45, "Philipp Kewisch"  wrote:

> Hey Folks,
>
> I'm a big fan of having development discussions in the open, and in the
> past #developers has been the prime place to do that. Even if the
> benefit may not be apparent vs. having a private discussion or using a
> closed channel, I think this is one of many ways to increase interest
> within the community. Back when I got started with Mozilla as a
> volunteer, I enjoyed reading discussions in #developers because they
> allowed me to peek into things that Mozilla developers were working on,
> and at times got me interested in the code that was being talked about.
>
> One thing that has recently "gotten in the way" of this is pulsebot. I
> acknowledge the usefulness of getting notifications on checkin, but it
> does add a lot of noise to #developers. Questions asked or discussions
> quickly fade away when pulsebot sends another dozen messages due to
> checkins and merges. How much exactly becomes apparent when you visit
> https://mozilla.logbot.info/developers/stats : pulsebot has said more
> than twice as much as anyone else.
>
> Of course you could say, why don't I just ignore pulsebot? The point is
> that only few will actually do so. My impression over time is that less
> of the questions I have asked are being answered, and my suspicion is
> that in part, people qualified to answer will just not see it in
> scrollback between all the pulsebot messages.
>
> Long story short, can we move pulsebot to a separate channel so that
> people can opt-in to, and encourage people to discuss their Gecko
> development topics in #developers again?
>
> Philip
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

[Kartikaya Gupta]

It's being investigated:
https://github.com/mozilla-releng/services/issues/707

On Nov 7, 2017 19:05, "Boris Zbarsky"  wrote:

On 10/4/17 10:32 AM, Jan Keromnes wrote:

> We've already disabled this "no defects" comment, and are currently
> deploying the fix to production, so the bot should stop sending them soon.
>

It looks like the "no defects" comment is back?  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1149250#c30 for example.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Next year in web-platform-tests

[Kartikaya Gupta]

On Fri, Dec 15, 2017 at 4:59 PM, Andreas Tolfsen  wrote:
> I would be interested to hear more about what primitives for user
> input emulation are required.

Touch input emulation would also be good. There are some CSS
properties like touch-action which require emulating user touch input
for proper testing. APZ testing would also be made easier if we had a
good mechanism for emulating user input. We have some stuff we've
cobbled together over time that we're using now but we have to add to
it for almost every new test we write which increases the pain barrier
for writing tests. :(

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: searchfox now indexes rust

[Kartikaya Gupta]

Just a heads-up, thanks to a bunch of work by Emilio, searchfox.org
now indexes rust code as well, so you can do things like jump to
function definitions and call sites and whatnot. Please use it and
file bugs under Webtools :: Searchfox for defects or feature requests.
I'm not sure how quickly we'll be able to fix them but it'll be good
to have stuff on file.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Inheriting annotations into included reftest.list files

[Kartikaya Gupta]

This will probably come as a surprise to many (as it does to me each
time I rediscover it), but if, in a reftest.list file, you do
something like this (real example from [1]):

skip-if(browserIsRemote) include ogg-video/reftest.list

this may not do what you expect. My expectation, at least, is that the
entire ogg-video/reftest.list file is skipped if the "browserIsRemote"
condition is true.

However, what *actually* happens is that the skip-if expected status
(which is EXPECTED_DEATH [2]) gets "inherited" down into the included
reftest.list, and if there's a higher-valued [3] annotation on a
reftest inside that included list, then that will "win". So in
practice, this means that any reftest inside ogg-video/reftest.list
that has a fuzzy() annotation, or a fuzzy-if(x) annotation where x is
true, will still run.

This seems like a very unexpected result, and looking through some of
the cases where this happens it's not at all clear to me if this was
intentional, or if these tests are just running accidentally because
nobody realized this would happen.

I'm happy to make changes to the reftest manifest parser to remove
this footgun (most likely by disallowing annotations on include
statements) but we would need to go through each instance of this in
the reftest.list files and fix things up so that the tests that are
running are in line with the expectations of whoever added/owns the
tests.

I wanted to open this up for discussion in case people have any
thoughts on it before I move forward and try to clean this up.

[1] 
https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/layout/reftests/reftest.list#275
[2] 
https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/layout/tools/reftest/manifest.jsm#228
[3] 
https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/layout/tools/reftest/globals.jsm#42
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Inheriting annotations into included reftest.list files

[Kartikaya Gupta]

Another option would be to keep allowing this syntax of "skip-if(x)
include some/reftest.list" but actually make it skip the entire
include if the condition "x" is true.

On Wed, Jan 10, 2018 at 10:49 AM, Kartikaya Gupta  wrote:
> This will probably come as a surprise to many (as it does to me each
> time I rediscover it), but if, in a reftest.list file, you do
> something like this (real example from [1]):
>
> skip-if(browserIsRemote) include ogg-video/reftest.list
>
> this may not do what you expect. My expectation, at least, is that the
> entire ogg-video/reftest.list file is skipped if the "browserIsRemote"
> condition is true.
>
> However, what *actually* happens is that the skip-if expected status
> (which is EXPECTED_DEATH [2]) gets "inherited" down into the included
> reftest.list, and if there's a higher-valued [3] annotation on a
> reftest inside that included list, then that will "win". So in
> practice, this means that any reftest inside ogg-video/reftest.list
> that has a fuzzy() annotation, or a fuzzy-if(x) annotation where x is
> true, will still run.
>
> This seems like a very unexpected result, and looking through some of
> the cases where this happens it's not at all clear to me if this was
> intentional, or if these tests are just running accidentally because
> nobody realized this would happen.
>
> I'm happy to make changes to the reftest manifest parser to remove
> this footgun (most likely by disallowing annotations on include
> statements) but we would need to go through each instance of this in
> the reftest.list files and fix things up so that the tests that are
> running are in line with the expectations of whoever added/owns the
> tests.
>
> I wanted to open this up for discussion in case people have any
> thoughts on it before I move forward and try to clean this up.
>
> [1] 
> https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/layout/reftests/reftest.list#275
> [2] 
> https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/layout/tools/reftest/manifest.jsm#228
> [3] 
> https://searchfox.org/mozilla-central/rev/03877052c151a8f062eea177f684a2743cd7b1d5/layout/tools/reftest/globals.jsm#42
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Inheriting annotations into included reftest.list files

[Kartikaya Gupta]

On Wed, Jan 10, 2018 at 3:40 PM, Daniel Holbert  wrote:
> I'd lean slightly towards allowing the syntax and making it actually skip
> the include expression.  This construct seems valuable to have in our
> toolbox (to be used only sparingly, e.g. for cases of platform-specific
> features).

Yeah I'm inclined to agree. I looked over the places where we are
currently doing this (the 11 in layout/reftests that you found, plus 3
more in image/test/reftest/reftest.list) and in all cases it seems
like the intent was to just skip the include entirely. So I'm planning
to change the semantics to do that, and disallow other annotations
like "fuzzy include foo/reftest.list" or "fails include
foo/reftest.list" - we don't have any of those currently and I think
disallowing them is the way to go.

I've filed bug 1429580 for this issue.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Inheriting annotations into included reftest.list files

[Kartikaya Gupta]

Closing the loop: the changes in bug 1429580 have landed, and so now
doing "skip-if(foo) include bar/reftest.list" behaves as one would
expect, and skips the include entirely if the foo condition is true.

On Wed, Jan 10, 2018 at 4:01 PM, L. David Baron  wrote:
> On Wednesday 2018-01-10 10:49 -0500, Kartikaya Gupta wrote:
>> This will probably come as a surprise to many (as it does to me each
>> time I rediscover it), but if, in a reftest.list file, you do
>> something like this (real example from [1]):
>>
>> skip-if(browserIsRemote) include ogg-video/reftest.list
>>
>> this may not do what you expect. My expectation, at least, is that the
>> entire ogg-video/reftest.list file is skipped if the "browserIsRemote"
>> condition is true.
>>
>> However, what *actually* happens is that the skip-if expected status
>> (which is EXPECTED_DEATH [2]) gets "inherited" down into the included
>> reftest.list, and if there's a higher-valued [3] annotation on a
>> reftest inside that included list, then that will "win". So in
>> practice, this means that any reftest inside ogg-video/reftest.list
>> that has a fuzzy() annotation, or a fuzzy-if(x) annotation where x is
>> true, will still run.
>>
>> This seems like a very unexpected result, and looking through some of
>> the cases where this happens it's not at all clear to me if this was
>> intentional, or if these tests are just running accidentally because
>> nobody realized this would happen.
>>
>> I'm happy to make changes to the reftest manifest parser to remove
>> this footgun (most likely by disallowing annotations on include
>> statements) but we would need to go through each instance of this in
>> the reftest.list files and fix things up so that the tests that are
>> running are in line with the expectations of whoever added/owns the
>> tests.
>>
>> I wanted to open this up for discussion in case people have any
>> thoughts on it before I move forward and try to clean this up.
>
> I think some of the mistake here is related to how fuzzy was
> implemented:
>
> For a start, fuzzy shouldn't have outranked skip in the list of
> statuses.
>
> But really, fuzzy is sometimes used in different ways:  it's
> sometimes used as a variation of the status (expected to pass,
> expected to fail, etc.) but also sometimes used a variation of the
> expected result (==, !=).  It's sort of a mess, since there are
> different understandings of what it should mean that make more or
> less sense for different uses.
>
> But I'd be fine just getting rid of annotations on 'include'
> directives.  They're confusing, and there was a substantial need for
> them for a short period of time (which was mostly about
> transitionally enabling tests on new platforms), but I think it's
> over.
>
> (If we need to keep skip for include directives, maybe we could at
> least get rid of the others, since if you go with dholbert's
> proposal skip would be processed in an entirely different way from
> the others.)
>
> -David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: searchfox now indexes rust

[Kartikaya Gupta]

On Fri, Jan 12, 2018 at 2:03 PM, Nicholas Alexander
 wrote:
> Does SF index non-trunk trees?  I can't find a way to search
> mozilla-{release,beta} right now.  Please correct me if it does?

It does not.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Core::Build Config has moved

[Kartikaya Gupta]

I was looking to file a bug in Core::Build Config and discovered it
doesn't exist any more. :mccr8 told me there is now a "Firefox Build
System" product that encompasses what used to be Core::Build Config.

I'm not a build peer so I don't know anything more than this; if
anybody wants more context hopefully the build peers can answer any
questions. This is just a heads-up in case anybody else goes looking
for the component.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Pointer Events (Desktop)

[Kartikaya Gupta]

Looks like it was enabled in
https://bugzilla.mozilla.org/show_bug.cgi?id=1411467

On Thu, Mar 15, 2018 at 1:23 PM,   wrote:
> Is there a specific bug for enabling this, aside from the meta implement bug?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: redundant(?) code churn and code style issues in bug 525063

[Kartikaya Gupta]

On Fri, Apr 13, 2018 at 6:18 AM, Jonathan Kew  wrote:
> It's presumably auto-generated by a static-analysis tool or something like
> that, but ISTM it has been overly aggressive, adding a lot more code churn
> than necessary (as well as committing some pretty extreme style violations
> such as over-long lines).

+1. I too was sad to see the style violations/general ugliness of the
changes in the patch.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Kartikaya Gupta]

On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez  wrote:
> I'd be ok with that I guess, though it's more common each time? Also, is
> there any case where you could use braces but not parenthesis? (I'm not a
> C++ expert in this regard).

I think there are. In particular if you're initializing a struct by
members which doesn't have a constructor. For instance, when I
recently upgraded layers id from a uint64_t to a struct, I had to use
{} in initializer lists instead of () because I didn't add a
constructor to the struct. Here's a simple example:

struct Foo {
int x;
};

struct Bar {
Bar()
: mFoo(0)   // <-- this fails, but {} will work
{
}

Foo mFoo;
};
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New policy: 48-hour backouts for major Talos regressions

[Kartikaya Gupta]

In general I'm in favour of this proposal, although it will probably
come back to haunt me in the not-too-distant future. That being said I
would like to know what criteria you used to distinguish "reliable"
talos tests from the rest.

kats

On Fri, Aug 14, 2015 at 5:26 PM, Vladan Djeric  wrote:
> The perf team and the A-Team would like to test out a new policy: we want
> to back out patches that cause significant Talos regressions on Windows
> builds. We would like to get developers’ feedback before starting this
> experiment.
>
> Why are we doing this?
>
> Essentially, we would like more Talos regressions to get fixed and Firefox
> performance to improve. We want to test a 48-hour backout policy because we
> noticed that patch authors often don't fix regressions quickly. If a
> regression sits in the tree for days, it becomes difficult to back out, and
> it becomes much more likely that the regression will end up riding the
> trains to Release by default.
>
> Note that we already have a policy of backing out regressions of 3% or more
> if the patch author does not respond at all on the regression bug for 3
> business days. See
> https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling
>
> The new policy is more aggressive. We think a patch that regresses
> performance significantly should be backed out quickly, and re-landed when
> its performance is acceptable.
>
> How will the backouts work?
>
> The A-Team perf sheriffs will create a Talos regression bug as soon as a
> regression is confirmed using Talos re-triggers. The patch author and
> reviewer will be CC’ed, and if they don’t provide an explanation for why
> the regression is acceptable, the patch will be backed out. The goal is to
> back out unjustified regressions within 48 hours of landing. We’d like to
> give the patch author about 24 hours to reply after the regression bug is
> filed.
>
> The A-Team has been working hard on improving the tools for understanding
> Talos regressions  (e.g. Perfherder), and we think debugging a Talos
> regression is a much less painful process these days. For example, there is
> now a highly usable view to visualize the comparison between a proposed
> patch against a baseline revision at
> https://treeherder.mozilla.org/perf.html#/comparechooser
>
> Will all regressions get backed out?
>
> No. Only regressions of 10% or more, on reliable Talos tests, on Windows,
> will face automatic backouts during this trial period. Given historical
> trends, we are anticipating about one backout per week.
>
>
> List of reliable Talos tests: ts_paint, sessionrestore, tp5o_scroll,
> tscrollx, tresize, TART, tsvgx, tp5o
>
> How are you testing this new policy?
>
> First off, we want developers’ feedback before trialing this new policy.
>
> I would like us to collect feedback and then start enforcing the new policy
> sometime next week. You can talk to us on the newsgroups or on #perf. You
> can also reach me directly (my IRC nick is “vladan”).
>
> We’ll post our conclusions on the newsgroups after a couple of months of
> enforcing the policy, and then we can all re-evaluate the backout policy
> together.
>
> Who will be the perf sheriffs?
>
> Joel Maher, Vaibhav Agrawal
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: Turning off Eideticker perf testing

[Kartikaya Gupta]

FWIW one of the original driver behind Eideticker (tuning Fennec for
checkerboarding during scrolling) will become relevant again in the
next couple of months as we transition Fennec to using the C++ APZ
code and off the old Java pan/zoom code. While it would be nice to
have Eideticker around to give us data on performance characteristics
during this transition, I'm not sure if it would be worth the effort
to get it up and running again.

kats

On Mon, Aug 17, 2015 at 5:38 PM, William Lachance  wrote:
> The Eideticker project (http://eideticker.mozilla.org) was started almost 4
> years ago, in an effort to better measure the performance of Firefox for
> Android by directly capturing video of the browser
> performing various actions. It later evolved to encompass testing FirefoxOS
> performance. It's an interesting approach and has produced useful results,
> especially during a period in 2012-2013 when we were tuning Firefox for
> Android to reduce checkerboarding and start up time.
>
> However, it hasn't received much maintenance over the last year, and some
> parts of the code (especially those to do with bisection and backfilling,
> which are critical to a useful performance harness) have bitrotted and no
> longer work. People have (correctly) criticized the set of tests that we run
> for lacking relevance: the content we use is old and sometimes esoteric and
> the Galaxy Nexus hardware we use is seriously out of date at this point. For
> these and other reasons, it's been over a year since a regression has been
> filed based on Eideticker data that has subsequently been addressed.
>
> Given enough time and resources, these issues could be fixed, but we just
> don't have them right now. My own attention has shifted to working on
> Perfherder and Talos, which has a much larger scope and impact in terms of
> the products we ship. We've made a fair bit of progress in this project over
> the last couple of quarters (see the recent announcement on 48-hour
> backouts), but for that to continue it needs more of my attention.
>
> Thus, I'd like to thus propose that we shut this system off for now. It goes
> without saying that the code (https://github.com/mozilla/eideticker) will
> live on, if we find out that we want to reactivate the project at some
> future point that should be totally possible.
>
> Will
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decreasing quality?

[Kartikaya Gupta]

There are some bugs about this (1189565 and 1193933 are the ones I'm
aware of), but please do file bugs if you haven't already and if your
symptoms don't match the existing bugs.

kats

On Thu, Aug 20, 2015 at 2:52 PM, Dirkjan Ochtman  wrote:
> On Thu, Aug 20, 2015 at 8:45 PM, Mike Hoye  wrote:
>> For what it's worth, living on Nightly + e10s + a multiscreen setup has been
>> pretty hard on the soul for a couple of months now, but I don't think that's
>> a sign of decreasing attention to quality or detail. That's just the price
>> of being in the crumple zone of a big, ambitious architectural change,
>> better we pay it on Nightly than release.
>
> Fair enough.
>
> BTW, there are also lots of issues in switching screens (or
> resolutions). E.g. at work my Firefox window regularly moves from
> Retina laptop screen to 27" normal screen, to TV screens, and Firefox
> sucks at redoing the layout to adapt to the changed viewport size.
> I've mentioned this a few times, but I'm not sure if there are any
> bugs about this stuff?
>
> Cheers,
>
> Dirkjan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is APZ meant to be a permanent part of the platform?

[Kartikaya Gupta]

I think that as it stands, yes, APZ is going to be a "permanent" part
of the platform. You're right that having higher-latency scroll events
creates some problems and makes it harder to drive animations off it.
We do have plans to provide more APIs for controlling things in the
compositor which should provide more ways to get to the 60fps goal
depending on what you're doing. Implementing CSS animations, scroll
snapping, position:sticky etc. in the compositor are examples of what
I mean. The Blink guys have been exploring other options as well -
things like CompositorWorker [1], where you can have some JS running
in the compositor at 60fps doing animations. So yes, there is some
ongoing discussion on this topic, but if you have thoughts on this
please do let us know.

Cheers,
kats

[1] e.g. 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/YlG2OvHgVaQ

On Sun, Oct 4, 2015 at 2:20 PM, Marcus Cavanaugh  wrote:
> APZ is wonderful, making the web feel smooth when a page's demands would
> otherwise cause jank. In many cases, it's the *only* reason we're able to
> create decent experiences today, particularly on mobile.
>
> It does, however, highlight a shortcoming of our platform today: we can't
> achieve flawless 60fps performance without APZ. We can get close, but any
> nontrival-but-reasonable demo will encounter jank, ostensibly due to
> compositing and rendering taking too much time. (APZ pathways, rendering
> the same content, provide consistent 60fps without frame drops, leading me
> to believe that some part of the JS-driven pipeline incurs substantial
> cost.)
>
> This means that on Firefox OS, the only way to achieve buttery-smooth
> touch-driven animations is to use overflow-scrollable containers rather
> than touch events. Scrollable containers provide a reasonable abstraction
> for user-driven fluid touch animations. If we had synchronous control over
> scroll events, we could do a lot more with just this; but because of APZ,
> we can only do so much:
>
> On Firefox OS, the "utility tray" (swipe down from the top of the screen)
> is now implemented with native scrolling. However, the tray's footer, which
> is intended to only appear when the tray reaches the bottom, cannot be
> displayed without visual glitches due to APZ -- the user can scroll the
> container before JS has a chance to react.
>
> My question is this: Is APZ intended to be a stopgap measure, to compensate
> for platform deficiencies in rendering performance, or is it intended to
> become a permanent part of the web? Put another way: Is "onscroll" forever
> redefined to be "an estimate of the current scroll position", rather than a
> synchronous position callback? (I thought I overheard talk about how
> WebRender might obsolete APZ due to its performance, but I may have
> misheard.)
>
> If APZ is with us forever (and 60fps JS-based animation is out of the
> question), then I think we need to create an API that allows sites to
> provide more fine-grained control over scroll motion. I have more thoughts
> on this, if APZ is the way forward.
>
> I'd also like to better understand why a natively-scrolled container is
> able to scroll at 60fps, while the same content scrolled with rAF +
> transforms cannot. If the rendered content is the same, where is the
> bottleneck? (I can provide test-cases/demos if desired.) I'd like to help
> out with addressing this deficiency, but I don't have enough Gecko
> experience to know where to begin.
>
>
> Marcus [:mcav]
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Date, time, week, month and datetime attributes in the in Firefox

[Kartikaya Gupta]

IMO given the number of people who have complained about the lack of this
feature on bug 825294, we should assume it is desirable to have even if
unstylable. If somebody claims otherwise the burden of proof should be on
them to show data that falsifies the assumption.

kats
On Sun, Nov 1, 2015 at 3:06 PM, Xidorn Quan  wrote:
> On Fri, Oct 30, 2015 at 6:57 PM, Jonas Sicking  wrote:
>> On Fri, Oct 30, 2015 at 12:36 AM, Xidorn Quan 
wrote:
>>> Authors sometimes just want something usable. It doesn't matter if it
>>> is not stylable, or it doesn't fit in the UI. When they really need to
>>> start caring about such things, they can switch to use jQuery UI then.
>>
>> I think this is true for a *very* small number of authors. Small
>> enough that we should spend our time on more impactful things.
>>
>> Look at the tooling websites that we use within mozilla. bugzilla.m.o,
>> treeherder.m.o, wiki.m.o and MDN all care about a pleasant look and
>> feel.
>
> OK, let's look at bugzilla.m.o. It uses ,  type="file/checkbox/radio"> without any special style on them. Do they
> look very bad within its context?
>
> Actually it seems to me, as we do not provide any decent method for
> styling things inside form controls, pushing people to mix normal form
> controls with jQuery UI components could be even worse for UI
> consistency.
>
>> Also remember that jQuery UI also works fine for websites that "just
>> wants something usable".
>
> It unnecessarily bloats the page. It requires the whole huge jQuery
> plus two additional jQuery UI files, which should have been completely
> avoidable for a page designed for modern browsers.

I'd really recommend talking to web developers rather than guessing at
their needs.

I hear *a lot* of webdevelopers complaining about the lack of ability
to style current controls. But don't take my word for it, do reach out
to developers, we have a developer relations team that I'm sure is
happy to help.

/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Kartikaya Gupta]

On Thu, Nov 26, 2015 at 8:50 AM, Thomas Zimmermann
 wrote:
> For anything non-AMO, the user is on
> their own.
>

I don't know if that would fly. As I understand it, a large part of
the purpose of extension signing is to protect users from malicious
add-ons that get installed by non-AMO means - sideloading, installed
by other apps, and so on. If we ignore the non-AMO add-ons then we're
not really solving any problems worth solving. (Caveat: I don't have
access to any actual data on the numbers and types of malicious
add-ons, but from what I've heard I believe this to be the case. I
could be wrong.)

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dan Stillman's concerns about Extension Signing

[Kartikaya Gupta]

So it seems to me that people are actually in general agreement about
what the validator can and cannot do, but have different evaluations
of the cost-benefit tradeoff.

On the one hand we have the camp (let's say camp A) that believes the
validator provides negligible actual benefit, because it is trival to
bypass, but at the same time provides a huge cost to add-on
developers. And on the other hand we have the camp ("camp B") that
believes the validator provides some non-negligible benefit, even
though it may significantly increase the cost to add-on developers.

>From what I have been told from multiple people, Mozilla does have
actual data on the type and number of malicious add-ons in the wild,
and it cannot be published. I don't really like this since it goes
against openness and whatnot, but I can accept that there are
legitimate reasons for not publishing this data. So the question is -
do the people in camp A or the people in camp B have access to this
data? I would argue that whoever has access to the data is in a better
position to make the right call with respect to the cost-benefit
tradeoff, and everybody else should defer to them. If people in both
camps have access to the data, then clearly they have different
interpretations of the data and they should discuss it further.
Presumably they know who they are.

kats


On Sat, Nov 28, 2015 at 10:35 AM, Eric Rescorla  wrote:
> On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch 
> wrote:
>
>> On 27/11/2015 23:46, dstill...@zotero.org wrote:
>>
>>> The issue here is that this new system -- specifically, an automated
>>> scanner sending extensions to manual review -- has been defended by
>>> Jorge's saying, from March when I first brought this up until
>>> yesterday on the hardening bug [1], that he believes the scanner can
>>> "block the majority of malware".
>>>
>>
>> Funny how you omit part of the quote you've listed elsewhere, namely:
>> "block the majority of malware, but it will never be perfect".
>>
>> You assert the majority of malware will be 'smarter' than the validator
>> expects (possibly after initial rejection) and bypass it. Jorge asserts,
>> from years of experience, that malware authors are lazy and the validator
>> has already been helpful, in conjunction with manual review.
>
>
> Did Jorge in fact assert that that as a matter of fact or as a matter of
> opinion?
> Maybe I missed it.
>
> This seems like an empirical question. how many pieces of obvious malware
> (in the sense that once the functionality is found it's clearly malicious
> code
> as opposed to a mistake, not in the sense that it's easy to find the
> functionality)
> have been found by the review process? How many pieces of obvious malware
> (in the sense above) have passed the review process or otherwise been
> found in the wild?
>
> -Ekr
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

APZ enabled on Fennec nightly

[Kartikaya Gupta]

Hi all,

Just a heads up that I landed the patch to enable APZ on Fennec
(nightly channel only for now). It should be in the Dec 1 nightly and
onwards. This will make scrolling around, and general touch input
handling, feel different on Fennec. The main improvement should be
that scrolling of iframes and overflow:scroll divs will be smoother
and faster.

If you find bugs, or behaviour differences that you feel make things
worse, please file them in the "Graphics, Panning and Zooming"
component of the "Firefox for Android" component and we'll take a
look.

Thanks!
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better mach support for Firefox for Android

[Kartikaya Gupta]

Thanks for all your work in making this happen! I've used some of
these commands recently and they work much better than they used to
for Fennec :)

On Mon, Nov 30, 2015 at 12:32 PM, Geoffrey Brown  wrote:
> In recent months, many improvements have been made to mach commands to
> support running, testing, and debugging Firefox for Android:
>
>  - More test commands for Android. These mach test commands now support
> Firefox for Android explicitly:
>
>   mach mochitest
>   mach robocop
>   mach reftest
>   mach crashtest
>   mach jstestbrowser
>   mach xpcshell-test
>   mach cppunittest
>
>
>  - Emulator support. 'mach android-emulator' launches the Android emulator,
> using the same Android image used to run tests seen on treeherder; select
> an image type with the --version option.
>
>  - All of the test, run, and debug commands offer to start the Android
> emulator if no Android device is connected (when run from an Android
> context).
>
>   $ ./mach mochitest testing/mochitest/tests/Harness_sanity
>   No Android devices connected. Start an emulator? (Y/n)
>
>  - All test, run, and debug commands offer to install Firefox on the
> connected device or emulator if Firefox is not already installed.
>
>   $ ./mach mochitest testing/mochitest/tests/Harness_sanity
>   It looks like Firefox is not installed on this device.
>   Install Firefox? (Y/n)
>
>  - Test commands requiring host xpcshell offer to install "host utilities"
> if none have been configured.
>
>  - Firefox can be run on an Android device or emulator with 'mach run'.
>
>  - JimDB, a GDB fork explicitly supporting debugging for Firefox for
> Android, can be installed, configured, and run with 'mach run --debug'.
>
>  - Emulator images, host utilities, and jimdb are automatically downloaded,
> cached, and installed as needed.
>
>  - Firefox for Android wiki pages have been updated:
> - Build info at https://wiki.mozilla.org/Mobile/Fennec/Android
> - Testing info at https://wiki.mozilla.org/Mobile/Fennec/Android/Testing
> - Debugging with GDB at
> https://wiki.mozilla.org/Mobile/Fennec/Android/GDB.
>
>  - Screencasts demonstrate common tasks at
> https://people.mozilla.org/~gbrown/android-demos/.
>
> Running, testing, and debugging Firefox will always be more complicated on
> Android than on desktop, but now these tasks look just as easy on Android,
> and can be performed with the same mach commands as on desktop.
>
> If you have had trouble in the past running, testing, or debugging your own
> Firefox for Android build, this is a great time to try again. All you need
> to get started is a Firefox for Android build on a Linux or OSX computer.
> Something not working for you? Have more ideas for improvements? Let me
> know.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APZ enabled on Fennec nightly

[Kartikaya Gupta]

Yes, I will be testing those features on Fennec later this week and
enabling them as well if they work well (or investigating why if they
don't). :)

On Tue, Dec 1, 2015 at 2:14 PM, Kearwood "Kip" Gilbert
 wrote:
> Excellent, Kats!!
>
> Perhaps this will also unblock smooth scrolling and scroll snapping for 
> fennec.
>
> Cheers,
>  - Kearwood “Kip” Gilbert
>
>> On Nov 30, 2015, at 8:37 AM, Kartikaya Gupta  wrote:
>>
>> Hi all,
>>
>> Just a heads up that I landed the patch to enable APZ on Fennec
>> (nightly channel only for now). It should be in the Dec 1 nightly and
>> onwards. This will make scrolling around, and general touch input
>> handling, feel different on Fennec. The main improvement should be
>> that scrolling of iframes and overflow:scroll divs will be smoother
>> and faster.
>>
>> If you find bugs, or behaviour differences that you feel make things
>> worse, please file them in the "Graphics, Panning and Zooming"
>> component of the "Firefox for Android" component and we'll take a
>> look.
>>
>> Thanks!
>> kats
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: APZ enabled on Fennec nightly

[Kartikaya Gupta]

Thanks for trying it out and reporting these issues! I've filed them
as separate bugs - bug 1229840, bug 1229839, and bug 1229841. We
should be able to address 2 and 3 by tuning some prefs, 1 will take a
bit more investigation.

Cheers,
kats

On Wed, Dec 2, 2015 at 11:31 AM,   wrote:
> Thanks for hard the work on this! I'm happy you're working on improving the 
> scrolling.
>
>
> Since the change, I've noticed a few things:
>
> 1. Reader mode's toolbar now sometimes seems to jump up and down several 
> times.
>
> 2. Deceleration takes too long to happen (the page seems to just float for 
> far too long after flings happen, especially for slower, smaller flings). 
> It's much slower than other apps, and it also feels much slower than I 
> remember for Firefox before the update.
>
> 3. Quick flings don't jump up or down on the page as quickly as they 
> previously did, making more work to get back up to the top of a page, or to 
> quickly jump down to read the summary paragraph of an article.
>
>
> This is all on a Nexus 6P running stock Android Marshmallow, by-the-way. It 
> might feel different on other devices.
>
>
> Again, thanks for working on this! I know it's a WIP in Nightly it's probably 
> subject to change a little with a few tweaks.
>
> Cheers,
> Garrett
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: SPS Profiles are now captured for entire subprocess lifetime

[Kartikaya Gupta]

\o/

Does this get us all the way to "profile talos runs with e10s
enabled", or are there still pieces missing for that? IIRC this set of
patches was a prerequisite for being able to do that.

On Thu, Dec 3, 2015 at 4:52 PM, Mike Conley  wrote:
> Just a heads up that there have been recent developments with regards to
> gathering SPS profiles from multiple processes.
>
> Bug 1103094[1] recently landed in mozilla-central, which makes it so that
> if a subprocess starts up _after_ profiling has already been started in the
> parent, then the subprocess will start profiling as well using the same
> features and settings as the parent.
>
> Bug 1193838[2], which is still on inbound, will make it so that if we are
> profiling while a process exits, we will hold onto that profile until the
> profiles are all requested by the parent process for analysis. Right now we
> hold these "exit profiles" in a circular buffer that's hardcoded at an
> arbitrary limit of 5 profiles.
>
> The upshot is that in many cases, if you start profiling, you'll not lose
> any profiles for subprocesses that start or finish before you choose to
> analyze the profiles. \o/
>
> Just wanted to point those out. Thanks to BenWa for the reviews! Happy
> profiling,
>
> -Mike
>
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1103094
> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1193838
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [webkit] More Responsive Tapping on iOS

[Kartikaya Gupta]

FWIW we support the fast-click on unzoomable pages and pages with
width<=device-width in the meta-viewport tag. We don't support touch-action
fully yet.

Cheers,
kats
On Dec 16, 2015 9:55 PM, "Karl Dubost"  wrote:

> Just a heads up about WebKit changing behavior on a couple of things.
>
> Bugs here refers to https://bugs.webkit.org/show_bug.cgi?id=
>
> * Bug 149968 - Web pages with unscalable viewports shouldn't have a single
> tap delay
> * Bug 150604 - Implement viewport-width-based fast-click heuristic
> * Bug 149854 - Implement touch-action: manipulation; for iOS
>
>
> The article on WebKit blog
> https://webkit.org/blog/5610/more-responsive-tapping-on-ios/
>
> Excerpt:
> > WebKit on iOS has a 350 millisecond delay before single taps activate
> links or buttons. WebKit has this delay because we also allow users to
> double tap to zoom, which is a great way to zoom in on content that is
> well-sized for large desktop displays, but appears too small on mobile
> devices. However, when a user has tapped once, WebKit cannot tell if the
> user intends on tapping again to trigger a double tap gesture. Since double
> tapping is defined as two taps within a short time interval (350ms), WebKit
> must wait for this time interval to pass before we’re sure that the user
> intended to tap only once.
> >
> > We know that responsive tapping is really important to web developers —
> so much so that many are willing to employ JavaScript frameworks to avoid
> the delay using touch handlers. Instead of waiting for WebKit to fire a
> click after a delay, these libraries prevent the default behavior of the
> touchend event and call `click()` immediately so that the element is
> clicked the moment the user stops touching the element. While this may make
> a link feel fast, it can also reduce responsiveness in other ways,
> including page load time and scrolling. To address this, we baked fast
> tapping optimizations into WebKit so well-scaled mobile web pages will be
> able to achieve responsive tapping out of the box without the drawbacks of
> third-party frameworks.
> >
> > On web pages optimized for mobile viewports, elements such as links and
> form controls are scaled to fit well on smaller screens. As such, double
> tapping on these elements increases the page scale by only a small amount.
> Since double tapping provides little value on these web pages, we’ve
> implemented a mechanism for removing the delay for single taps by disabling
> double tap gestures.
> >
> > The following examples show the amount of time required to tap a button
> 10 times in a page with ``, with and without the fast-tap optimization. The left
> video shows the old behavior, while the right video shows the new behavior.
> >
> > ### When Fast-Tap Optimizations Apply
> >
> > When content is scaled to fit well on a mobile device, WebKit disables
> double tapping in favor of fast single tapping. Using the viewport meta
> tag, there are a few ways WebKit determines whether content is
> well-proportioned, for both scalable and unscalable web pages.
> >
> > Since users cannot zoom in unscalable viewports (using meta tags with
> `user-scalable=no` or a `minimum-scale` equal to the `maximum-scale`)
> WebKit assumes that if a page has an unscalable viewport, all content is
> already well-proportioned relative to the screen. On these pages, WebKit
> removes the ability to double-tap on elements altogether and dispatches all
> taps immediately as clicks. We implemented this behavior in [Bug #149968](
> https://bugs.webkit.org/show_bug.cgi?id=149968).
> >
> > However, we believe web pages should be scalable when possible. For this
> reason, viewports that have `width=device-width` will have fast single
> tapping when the user is at initial scale. We added this optimization in
> [Bug #150604](https://bugs.webkit.org/show_bug.cgi?id=150604).
> >
> > ### Styling Fast-Tap Behavior
> >
> > Even if a web page cannot use one of the viewport configurations above,
> it can still opt in to the fast-tap optimization. We’ve implemented the
> `manipulation` value of the new `touch-action` CSS property in [Bug
> #149854](https://bugs.webkit.org/show_bug.cgi?id=149854). By default,
> elements have `touch-action: auto`, which indicates that WebKit may enable
> any touch behaviors such as panning, pinching and double-tapping. Putting
> `touch-action: manipulation;` on a clickable element makes WebKit consider
> touches that begin on the element only for the purposes of panning and
> pinching to zoom. This means WebKit does not consider double-tap gestures
> on the element, so single taps are dispatched immediately. Single taps on
> an element become fast when any of the element’s ancestors have the
> `touch-action: manipulation`. Note that putting `touch-action:
> manipulation` on any node opts all children of the node into the fast-tap
> optimization.
> >
> > Additionally, single taps on an element with `touch-action:
> manipulation` are fast for all zoom scales, whereas 

Re: about:profiles and the new profile manager

[Kartikaya Gupta]

Note that there are add-ons such as "Profile Switcher" which allow you
to display the profile manager dialog without touching the
command-line. I don't know if that qualifies as "user facing" or not.
It's certainly an advanced user feature that most people will never
see.

kats

On Fri, Dec 18, 2015 at 5:15 PM, Bobby Holley  wrote:
> I believe he means that the current profile manager isn't really
> user-facing, since it needs to be enabled on the command line (at least
> once): http://kb.mozillazine.org/Profile_Manager
>
> The current profile manager certainly doesn't meet our UX standards, so we
> shouldn't try to make the replacement meet them either. That being said, we
> should make sure it's no _less_ usable than the old one.
>
> bholley
>
> On Fri, Dec 18, 2015 at 2:09 PM, Stephen Horlander 
> wrote:
>
>> On Friday, December 18, 2015 at 4:52:00 PM UTC-5, Benjamin Smedberg wrote:
>> > As it stands, this is not intended to be product code and so I
>> > specifically advised Andrea not to spend UX/product time on this. It is
>> > still a strict replacement for the old profile manager code which was
>> > very difficult to maintain.
>> >
>> > It's unlikely that we'd use this code as a base for any production
>> > version of multiple-user Firefox.
>> >
>> > --BDS
>>
>> I am not sure I understand. Does "not intended to be product code" mean
>> that this won't be riding the trains and shipping in a general release of
>> Firefox?
>>
>> - Stephen
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Too many oranges!

[Kartikaya Gupta]

Is it just me, or has the number of intermittent oranges gone up quite
a lot in the last couple of months? It seems like every try push I do
has a lot of oranges which are completely unrelated to may patch.
Clearly everbody has more urgent things to do than fix intermittent
failures (myself included) but the net result is a lot of wasted time
starring bugs and digging through failures to see if they are
legitimate or not.

So, I propose that we create an orangefactor threshold above which the
tree should just be closed until people start fixing intermittent
oranges. Thoughts?

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

[Kartikaya Gupta]

On Mon, Dec 21, 2015 at 3:11 PM, L. David Baron  wrote:
> I agree it's definitely gone up recently, and agree that it causes a
> lot of wasted time.  I'm not convinced about closing the tree,
> though; keeping the tree closed for extended periods just leads to
> big backups.
>
> How about everybody reading this message takes a look at the list on
> http://brasstacks.mozilla.com/orangefactor/ and takes one of them to
> fix?  (Or, better, redoes the search filtered on the last 3 days
> instead of last 7.)


I feel like a voluntary approach is likely to have very little effect,
given the way our goals and priorities are structured. There's very
little incentive to voluntarily spend time banging your head against a
wall. That's why I'm more in favor of a forced approach that is
mandated by managers/product owners/sheriffs (i.e. people who can
actually tell us to some extent what to do).

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

[Kartikaya Gupta]

Personally I much prefer the new approach to reporting intermittents.
It's much easier for me to see at a glance (i.e when the bugs are
updated with the weekly count) which ones are actually occurring more
frequently and which bug would be best to spend time on. With the old
system I just got so much intermittent-failure bugmail that I would
just ignore it all.

kats

On Tue, Dec 22, 2015 at 11:08 AM, Ben Kelly  wrote:
> Does anyone feel the changes to how intermittents are reported to bugs has
> affected things?  We used to get a comment for each intermittent, but now
> its rolled up into a periodic summary.  Perhaps people feel less urgency to
> fix things without the constant bugmail.  Not that I want to advocate
> spam...  but it is a recent change.
>
> On Tue, Dec 22, 2015 at 10:40 AM, Mike Conley  wrote:
>
>> I would support scheduled time[1] to do maintenance[2] and help improve our
>> developer tooling and documentation. I'm less sure how to integrate such a
>> thing in practice.
>>
>> [1]: A day, a week, heck maybe even a release cycle
>> [2]: Where maintenance is fixing oranges, closing out papercuts,
>> refactoring, etc.
>>
>> On 21 December 2015 at 17:35,  wrote:
>>
>> > On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta wrote:
>> > > So, I propose that we create an orangefactor threshold above which the
>> > > tree should just be closed until people start fixing intermittent
>> > > oranges. Thoughts?
>> > >
>> > > kats
>> >
>> > How about regularly scheduled test fix days where everyone drops what
>> they
>> > are doing and spends a day fixing tests? mc could be closed to everything
>> > except critical work and test fixes. Managers would be able to opt
>> > individuals out of this as needed but generally everyone would be
>> expected
>> > to take part.
>> >
>> > Jim
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

[Kartikaya Gupta]

On Tue, Dec 22, 2015 at 11:16 AM, Douglas Turner  wrote:
> Mike -- totally supportive of this. I would *love* to see a release cycle
> completely dedicated to quality.  We branch again on January 26.  We could
> use that cycle to focus on nothing but quality (fixing tests, bug triaging,
> no feature development at all).
>
> Thoughts?
>

I'm in favour of this. I'm assuming that the "spring release"
marketing is going to be focused around Firefox 46, so it would be
nice to spend the 47 nightly just doing quality fixes. More generally
it would be great to spend two releases a year (the first ones after
the fall/spring releases) just doing cleanup work.

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding jobs to pushes having some issues

[Kartikaya Gupta]

For the record it seems like even if adding new jobs via TH fails, the
old try-extender tool at http://try-extender.herokuapp.com/ still
works (at least for try pushes).

On Tue, Dec 22, 2015 at 2:56 PM, Armen Zambrano G.  wrote:
> Hello team,
> Thanks for using the ability of adding jobs to your pushes from
> Treeherder [1].
>
> I want to point out that some of you are having a great experience and
> others not seeing anything happen or not all jobs being available.
>
> There are some bugs in the code and efforts will be made in January to
> improve the experience.
>
> Alternative you can triggerbyfilters.py from the command line [2].
>
> Until then, feel free to file bugs under Testing::General and CC me.
>
> My apologies for the issues.
>
> regards,
> Armen
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1233807
> https://bugzilla.mozilla.org/show_bug.cgi?id=1234552
>
> [1] http://explique.me/TH/
> [2]
> https://mozilla-ci-tools.readthedocs.org/en/latest/scripts.html#triggerbyfilters-py
>
> --
> Zambrano Gasparnian, Armen
> Automation & Tools Engineer
> http://armenzg.blogspot.ca
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Thanks for all the great teamwork with the Sheriffs in 2015!

[Kartikaya Gupta]

Yes, thank you to all the sheriffs for all their hard work!

On Wed, Dec 30, 2015 at 9:19 AM, Carsten Book  wrote:
> Hi,
>
> Sheriffing is not just about Checkins, Uplifts and Backouts - its also a
> lot of teamwork with different Groups and our Community like Developers, IT
> Teams and Release Engineering and a lot more to keep the trees up and
> running. And without this great teamwork our job would be nearly impossible!
>
> So far in 2015 we had around:
>
> 56471 changesets with 336218 changes to 70807 files in mozilla-central
> and 4391 Bugs filed for intermittent failures (and a lot of them fixed).
>
> So thanks a lot for the great teamwork with YOU in 2015 - especially also a
> great thanks to our Community Sheriffs like philor, nigelb and Aryx who
> done great work!
>
> I hope we can continue this great teamwork in 2016 and also the monthly
> sheriff report with interesting news from the sheriffs and how you can
> contribute will continue then :)
>
> Have a great start into 2016!
>
> Tomcat
> on behalf of the Sheriffs-Team
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

APZ on desktop: riding the trains on Gecko 46

[Kartikaya Gupta]

Just a heads up that APZ for desktop, which has been enabled in
Nightly for a few releases now, will be riding the trains on Gecko 46.
There are still a few open blockers hanging off bug 1178298 but we
expect to have them fixed shortly.

APZ being enabled is still conditional at runtime on e10s being
enabled. Since e10s is planned to roll out progressively in 45 and 46
we don't plan to support APZ without e10s. APZ will be enabled for
wheel input on Windows, Linux, and OS X, and also for trackpad
scrolling on OS X. In future releases we plan to expand this support
to other input methods including touch, keyboard, and scrollbar
dragging.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding new jobs to pushes in better shape

[Kartikaya Gupta]

Thanks! I just used this on inbound and it seems to be working well. :)

On Thu, Jan 21, 2016 at 9:26 AM, Armen Zambrano G.  wrote:
> I've spent the last two days fixing most issues affecting adding jobs on
> Treeherder.
> I believe it is now working properly.
> You don't need to try multiple times.
>
> Remember:
> * this does not work with TaskCluster jobs [1]
> * if you own the push, you can add jobs
> * if you use and @mozilla.com, you have full privileges
> * if you need to be whitelisted because you have a non @mozilla.com
> address let me know
>
> More improvements are needed [2] to give you proper feedback and make
> this a production worthy system, however, it should work for now.
> If it doesn't, please let me know (file bugs under Testing:General and
> CC me).
>
> regards,
> Armen
>
> [1]
> https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=tc
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=push_extender
>
> --
> Zambrano Gasparnian, Armen
> Engineering productivity engineer
> http://armenzg.blogspot.ca
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Kartikaya Gupta]

I also want to highlight the thing at the end of the gist linked above
- the majority of the non-SSE2 population are on 43.0.4. That is,
they're keeping up-to-date, and would likely be affected by this more
than somebody stranded on an old version.

On Fri, Jan 29, 2016 at 3:29 PM, Chris H-C  wrote:
> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
> "hasSSE2" detected.
>
> Here's the analysis and results on github. Please feel free to check my
> work: https://gist.github.com/chutten/4959c873d7fbbec0785a
>
> Keep in mind we cannot prove a negative from this. I cannot state that
> those pings without hasSSE2 correspond to clients that don't have SSE2
> support on their machines. So I tried (and failed, see bottom section of
> that gist) to keep analysis and discussion centred on the "hasSSE"
> population alone.
>
> :chutten
>
> On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye  wrote:
>
>> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>>
>>> On 1/29/16 9:43 AM, Ashley Gullen wrote:
>>>
 FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
 "other settings"): http://store.steampowered.com/hwsurvey

>>>
>>> For that to be valid, one must assume that the population of Firefox
>>> users and Steam users are sufficiently similar. I don't think that's
>>> necessarily true since most Steam titles have substantially higher system
>>> requirements.
>>>
>> While that's a fair point, Microsoft turned compiling with SSE2 on by
>> default in Visual Studio in 2012, and it's been basically impossible to buy
>> an x86 CPU without it since...  2004 or so?
>>
>> I've tapped chutten about this, and he says:
>>
>> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
>> contains "SSE2"
>> 14:33 < chutten> or, rather, the inverse
>>
>> ... which he then explained to me means "we can get our own data in short
>> order."
>>
>> He says it'll be straightforward to pull in, so he's going to do that.
>>
>>
>> - mhoye
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Touch events enabled on Windows desktop (nightly only)

[Kartikaya Gupta]

In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
Windows desktop builds. This should be in Jan 31 nightly. For devices
that have touchscreens, this has two effects:

1) Touch scrolling now uses APZ. The physics will probably need some
tuning, but if you see correctness issues with scrolling, tapping,
long-tapping, etc., please file a bug and cc me. Pinch zooming is
currently disabled.

2) Web content will be receiving touch events. This may result in
pages responding very differently when using touch to interact with
it. Pages may also do different things on load, because they can
detect the presence of touch interfaces via window.Touch and
window.TouchEvent which wasn't the case before. If you observe
strange/buggy behaviour on touchscreen windows devices that wasn't
there before, try setting dom.w3c_touch_events.enabled to false
(restart required) to confirm it was caused by this change, and please
file a bug and cc me if so.

For the moment this change will remain on Nightly until we are
confident that it doesn't break anything major.

Note also that touch event support has been enabled on Linux for a
while now (not just Nightly) although you need MOZ_USE_XINPUT2=1 in
the environment for it to work. If you have a Linux touchscreen device
please feel free to try it out there as well and file bugs if you
encounter any problems.

Thanks!
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Touch events enabled on Windows desktop (nightly only)

[Kartikaya Gupta]

Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e10s is disabled, APZ is disabled, which means no APZ
touch scrolling. If you encounter bugs in this configuration, again,
please file. If you want to force-enable e10s (and therefore APZ), you
can set the browser.tabs.remote.force-enable pref to true.

On Mon, Feb 1, 2016 at 12:46 PM, Kartikaya Gupta  wrote:
> In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
> Windows desktop builds. This should be in Jan 31 nightly. For devices
> that have touchscreens, this has two effects:
>
> 1) Touch scrolling now uses APZ. The physics will probably need some
> tuning, but if you see correctness issues with scrolling, tapping,
> long-tapping, etc., please file a bug and cc me. Pinch zooming is
> currently disabled.
>
> 2) Web content will be receiving touch events. This may result in
> pages responding very differently when using touch to interact with
> it. Pages may also do different things on load, because they can
> detect the presence of touch interfaces via window.Touch and
> window.TouchEvent which wasn't the case before. If you observe
> strange/buggy behaviour on touchscreen windows devices that wasn't
> there before, try setting dom.w3c_touch_events.enabled to false
> (restart required) to confirm it was caused by this change, and please
> file a bug and cc me if so.
>
> For the moment this change will remain on Nightly until we are
> confident that it doesn't break anything major.
>
> Note also that touch event support has been enabled on Linux for a
> while now (not just Nightly) although you need MOZ_USE_XINPUT2=1 in
> the environment for it to work. If you have a Linux touchscreen device
> please feel free to try it out there as well and file bugs if you
> encounter any problems.
>
> Thanks!
> kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Touch events enabled on Windows desktop (nightly only)

[Kartikaya Gupta]

Thanks for the pointer to the metabug! I'll keep an eye on it and try
to test those issues to see if they still happen. This was a major
concern for me as well, which is why this is Nightly-only for now.
Even if there are sites that are broken I definitely think we should
push hard to get them fixed because we can't not support touch
forever.

On Wed, Feb 3, 2016 at 10:01 AM, Jim Mathies  wrote:
> On Monday, February 1, 2016 at 11:50:44 AM UTC-6, Kartikaya Gupta wrote:
>> In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
>> Windows desktop builds. This should be in Jan 31 nightly. For devices
>> that have touchscreens, this has two effects:
>
> The last time we turned this on it caused numerous problems. Please see bug 
> 806805 for a list of issues that cropped up.
>
> One problem is that the touch events we send from win32 widget aren't spec, 
> the other involved sites that started treating desktop like mobile. We ended 
> up having to turn touch events off due to these issues.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Gecko/Firefox stats and diagrams wanted

[Kartikaya Gupta]

+ Sotaro, who has over the years created a lot of different
architecture/class diagrams of different parts of Gecko. They might be
too detailed for your needs but worth checking.

On Tue, Feb 9, 2016 at 12:31 PM, Nicholas Alexander
 wrote:
> +Kyle, +Nathan
>
> On Tue, Feb 9, 2016 at 9:00 AM, Chris Mills  wrote:
>
>> Hi all,
>>
>> I’m writing a presentation about browsers, standards implementation, and
>> cross-browser coding to give at some universities. As a part of it, I
>> wanted to present some stats about Firefox/Gecko to show how many people on
>> average commit to it (say, every month, every year?), how many people work
>> on localising the content strings, how many people work on platform/UI
>> features, etc.
>>
>
> Kyle Lahnakoski has done some work in this area -- he set up a neat
> contributor dashboard.  Perhaps Kyle has more data about paid activity
> too.  I'm CCing him to see if he can say more.  I imagine Mike Hoye has
> much to say here.
>
>
>> I also wanted to try to find some diagrams to show how Firefox and Gecko
>> work/their architecture, from a high level perspective (not too insane a
>> level of detail, but reasonable).
>>
>
> Nathan Froyd worked up a very high-level slide deck for his onboarding
> sessions; they're amazing.  I'm not sure how public those slides are, so
> I've CCed him and he may choose to link to those.  I would really love to
> see these worked up into a document rather than a presentation.
>
> Thanks for doing this work!
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kartikaya Gupta]

On Thu, Mar 10, 2016 at 5:45 PM, Anthony Jones  wrote:
> My understanding is that the reason people stick to 10.6 is because of
> Rosetta[1] which offers PowerPC compatibility.

I have a laptop on 10.6. The hardware can theoretically support newer
OS X versions, and I've upgraded it, but newer OS X versions are
severely unstable on it, causing hangs and spontaneous OS reboots. So
I downgraded back to 10.6. I don't know if this is a common scenario
but given Apple's hardware uniformity I'm probably not the only one
who has experienced this. Just saying Rosetta isn't the only reason
people stay on 10.6 :)

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Testing Wanted: APZ Scrollbar dragging

[Kartikaya Gupta]

On Apr 1, 2016 2:45 AM, "Sam Harrington" 
wrote:
> I've been seeing some rather weird middle-click scrolling behavior in
recent nightlies, and your test page seems to be a good way to reproduce it
(see https://gfycat.com/FarflungCoarseBoutu for a video). Is this a known
issue, or should I file it?

This sounds very similar to
https://bugzilla.mozilla.org/show_bug.cgi?id=1259781 (see the screencast
linked on that bug). If you think this is a different issue then please
file a new bug in the same component as that bug. Thanks!

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Kartikaya Gupta]

It seems to me that when this bug program was started, it had these
two goals (quoted from Emma's previous email):

"First, we want
to make better assertions about the quality of our releases by making clear
decisions about which bugs must be fixed for each release (urgent) and
actively tracking those bugs. The other is the number of good bugs filed by
our community. Filing a bug report is a gateway to greater participation in
the Mozilla project, and we owe it to our community to make quick and clear
decisions about each bug."

Somewhere along the way this got conflated with "all teams must use
the same process to indicate how bugs got triaged". While I'm sure
that doing so provides additional benefits, I'm not sure it's
necessary to accomplish the goals stated above, and might actually be
counterproductive initially. Some teams already have processes in
place for triaging and annotating bugs, and have been using their
process for quite some time. Forcing them into a new process seems
unnecessary if what they are doing already works for them. I think
what's more important is that each component have an owner (or
owners), and that the triage process for that component is documented
somewhere and followed. For those teams that don't already have a
triage process or that are looking to change their process, I think
it's a great idea to have a canned "this is the recommended approach
we know has worked for some teams" ready for them to use. Dictating
specific process rather than allowing teams to find their own way to
meet the requirements is overkill.

If you do want to expand the scope of this proposal to add more
uniformity across Mozilla then that should be explicitly stated as a
goal. Personally, I think that might be better done as a follow-up
effort after looking at the variety of triage processes that different
teams use and finding something that is general enough to work for
everybody.

Cheers,
kats

On Fri, Apr 1, 2016 at 4:35 AM, Marco Bonardo  wrote:
> On Fri, Apr 1, 2016 at 2:02 AM, Emma Humphries  wrote:
>
>> Priority sounds like a great choice, but given that everyone's using the
>> Priority field their own way, there's enough heterogeneity in how it's used
>> to make it difficult.
>>
>
> Fwiw, we (Awesome Search Team) also use Priority for the backlog, and we
> consider P1, P2 and P5 the same as Media Playback team. So there is some
> convergence about the meaning of those.
> Though we also use P3 for "we care about this and will fix it, provided
> there's no major priority bug to fix first". This helps planning future
> work, by retriaging P3s into P2s when the list of P2s shrinks or new goals
> are made. The P5 pool would be too large to pick things out of it.
> Merging P4 into P5 wouldn't make much of a difference. Both are things we
> recognize are valid bugs, but it's very unlikely we'll ever have time to
> fix them.
>
> Imo, merging everything below P2 into a single backlog is a mistake,
> there's quite a huge difference between "we want to fix this once there's
> time but it's not critical now" to "we are unlikely to ever have time to
> fix this". I personally feel the need for a "P3" category.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Coding style for C++ enums

[Kartikaya Gupta]

Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, and update the style guide
accordingly.

enum OptionA {
  ALL_CAPS_VALUES,
  THIS_IS_LIKE_SHOUTING
};

enum OptionB {
  SentenceCaseValues,
  ThisMightBeConfusedWithOtherThings
};

enum OptionC {
  eSentenceCaseValues,
  eThisSeemsPopular
};

Others?

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Kartikaya Gupta]

On Fri, Apr 8, 2016 at 10:54 AM, Benjamin Smedberg
 wrote:
> On Thu, Apr 7, 2016 at 2:50 AM, L. David Baron  wrote:
>> Why it's important
>> What makes this problem important or urgent to fix?
>>
>
> Yes! If this isn't clear, who owns this? Either the module owner/peer, or a
> product manager, usually. Are there cases where we don't know?
>

In my experience this piece is often the most unclear. If we trying to
be more product-focused, then I think ultimately the product manager
should have the final say on the urgency of any user-visible bug.
However, in order to make an informed decision, they need to have
information about how frequently and under what circumstances the bug
occurs. Usually that information is not available without doing some
sort of time-consuming investigation as to the root cause. This
approach requires a high amount of bandwidth from the product
management team (they have to look at a lot of bugs) as well as the
dev team (lots of investigation into root causes).

In practice this tends decision tends to "gracefully degrade" into a
process where the module owner/peer looks at the bug, makes a guess as
to how bad it is, and requests tracking if it's worse than some
arbitrary/subjective threshold, and product management may not even
see it until much later (when it's already on aurora/beta, for
example). I'm not sure what we can do to improve this process exactly,
but I feel like there's room to make it more objective and clear-cut
without requiring extra bandwidth. I'm thinking of something along the
lines of a wiki page or some documentation that provides more
objective guidelines as to when a bug should be marked as tracking,
that the module owners/peers/triagers can reference when trying to
decide.

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style for C++ enums

[Kartikaya Gupta]

Based on all the feedback so far I think the best compromise is to use
enum classes with the "e" prefix on the values. As was mentioned, the
"e" prefix is useful to distinguish between enum values and function
pointer passing at call sites, but is a small enough prefix that it
shouldn't be too much of a burden.

I realize not everybody is going to be happy with this but I don't
want this discussion to drag on to the point where it's a net loss of
productivity no matter what we end up doing. I'll update the style
guide.

Thanks all!

kats


On Sun, Apr 10, 2016 at 11:43 AM, smaug  wrote:
> On 04/10/2016 05:50 PM, Aryeh Gregor wrote:
>>
>> On Fri, Apr 8, 2016 at 8:35 PM, smaug  wrote:
>>>
>>> enum classes are great, but I'd still use prefix for the values.
>>> Otherwise the values look like types - nested classes or such.
>>> (Keeping my reviewer's hat on, so thinking about readability here.)
>>
>>
>> In some cases I think it's extremely clear, like this:
>>
>>enum class Change { minus, plus };
>>
>> whose sole use is as a function parameter (to avoid a boolean
>> parameter), like so:
>>
>>ChangeIndentation(*curNode->AsElement(), Change::plus);
>>
>> In cases where it might be mistaken for a class, it might make more
>> sense to prefix the enum class name with "E".  I don't think this
>> should be required as a general policy, though, because for some enums
>> it might be clear enough without it.
>>
>
> Indeed in your case it is totally unclear whether one is passing a function
> pointer or enum value as param.
> If the value was prefixed with e, it would be clear.
>
> Consistency helps with reviewing (and in general code readability) a lot, so
> the less we have optional coding style rules, or
> context dependent rules, the better.
>
>
>
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style for C++ enums

[Kartikaya Gupta]

On Mon, Apr 11, 2016 at 1:46 PM, Seth Fowler  wrote:
> I'd honestly prefer to see this discussion drag on a little longer. The
> original email was on Friday, so given that most participants on this list
> aren't actively debating C++ coding style on the weekend, we've actually had
> less than one full working day of discussion on this issue so far.

And that's about as long as I think is worthwhile spending on the
discussion :) Feel free to continue discussing if you like, and if
there's a strong sentiment against the decision I made we can change
it.

> Let me suggest again (especially since I'm not sure my previous email
> reached this list yet) that rather than compromise on the "e" prefix, we
> compromise on all caps for values, which is just as readable without placing
> even more pressure on our 80-character line length restriction.

All caps actually makes long names *longer* because you now need to
add underscores to separate words, rather than using sentence case.
For example eSentenceCase is the same length as SENTENCE_CASE, but if
you tack on another word the "e" prefix is shorter. Presumably this
line-wrapping issue is more pronounced with long names than short
names, so this is actually an argument against all caps.

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

[Kartikaya Gupta]

He seems to have gotten the message:
https://bugzilla.mozilla.org/show_bug.cgi?id=1255526#c21

On Mon, Apr 11, 2016 at 6:47 PM, Mark Côté  wrote:
> Tagging the comments as spam will autoban the account after a certain
> number.  It will also autocollapse the comments.
>
> Mark
>
>
> On 2016-04-11 6:35 PM, Lawrence Mandel wrote:
>> Good intentions or not, we need to stop this activity.
>>
>> Mark - What's our usual approach to address bug spam?
>>
>> Lawrence
>>
>> On Monday, 11 April 2016, Mats Palmgren  wrote:
>>
>>> On 2016-04-11 23:32, Emma Humphries wrote:
>>>
 Here's the open bugs they have touched http://mzl.la/1Q3w24o

>>>
>>> He touched 283 bugs in the last 48 hours, most of which are FIXED.
>>>
>>> Many comments are identical, for example:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240762
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240778
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240670
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1240682
>>>
>>> All four have identical comments, added in a time span of 15 seconds.
>>>
>>> /Mats
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Kartikaya Gupta]

I also often have multiple pushes going at the same time. My
suggestion to solve this problem is: have a cron job that detects
users who have more than N pushes with jobs still going, and send them
an email saying "you have a lot of jobs going, here's the list; you
might find something you should cancel in there".

Personally, I do keep an eye on my pushes and try to cancel stuff as
it becomes unnecessary, but sometimes there might be a few pending
jobs on very old pushes that I've neglected to cancel, and will likely
not push with that bug number anymore. An email reminder that lists
those old pushes would make me realize I can cancel them.

kats


On Fri, Apr 15, 2016 at 4:02 PM, Boris Zbarsky  wrote:
> On 4/15/16 1:09 PM, Tim Guan-tin Chien wrote:
>>
>> I wonder if there is any use cases to do multiple Try pushes of different
>> changesets but with the same bug number.
>
>
> A significant fraction of my try pushes are like this, actually. Typically
> this happens when I do a try push of a multi-changeset queue for a bug, get
> some mysterious failures, then do several pushes of more and more of the
> queue in an attempt to narrow down which changeset is causing the failures.
>
>> Should we automatically cancel the old ones when there is a new one?
>
>
> If we set this up, I would probably just add whatever the "do not cancel"
> override is to my try syntax for everything, to avoid the inevitable
> footguns.  Unless there were a way to uncancel.
>
> -Boris
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Kartikaya Gupta]

On Apr 17, 2016 1:55 PM, "Steve Fink"  wrote:
>
> Generally speaking, Firefox's stability has not been good for me for 2-3
months. I'd like to file a bug, but I've already used up my quota of
unactionable bugs, and if I dug into all of my idiosyncratic issues I'd
never get any work done.

Also (and I don't mean to single out sfink; I've heard similar things from
other people, and have been guilty of this myself) - filling bugs and
digging into issues *is* work, so saying "I'd never get any work done"
really means "I won't be able to get around to what I'm supposed to be
doing instead".

My view is that if we have a lot of bugs and regressions, time spent
investigating and fixing those naturally acts as a backflow to new feature
work, which prevents the introduction of even more bugs and regressions. So
really time spent investigating these issues is good in that it encourages
a self-correcting cycle, rather than just adding more regressions and work
for everybody that will never get done.

Of course, the tradeoff is that we have this goals system where you have to
state up front what you are going to do in a quarter and that makes it
harder to justify spending time on these other issues that often take a lot
of time as you poke around in unfamiliar code. Also falling behind on
features means we fall behind other browsers from a user perspective. My
interpretation of the push on quality, though, is that this is correct
tradeoff to make for us at this time, because great bug-free experiences
are more useful to us right now than a pile of half-baked features.

Cheers,
kats

>
>
> On 04/16/2016 08:32 PM, Nicholas Nethercote wrote:
>>
>> I use T-pushes on try a lot, where I build on all platforms (debug and
>> opt) but run tests only on one platform (debug and opt), usually
>> Linux64. I.e.: "try: -b do -p all -u none[x64] -t none[x64]".
>
> I think you meant "try: -b do -p all -u all[x64] -t all[x64]".
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving XP to ESR?

[Kartikaya Gupta]

On Mon, Apr 18, 2016 at 2:02 PM, Chris Peterson  wrote:
>
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.
>

>From data that Chris H-C posted in some previous thread, we know that
Firefox users on XP are using recent versions of Firefox. I suspect
Chrome users on XP are probably also using recent versions of Chrome,
and may care about staying up-to-date.

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

(Cross-posted to dev-platform and release-management)

Hi all,

Not too long ago I ran a telemetry experiment [1] to figure out how to
tune some of our code to get the best in-the-wild behaviour. While I
got the data I wanted, I found the process of getting the experiment
going to be very heavyweight as it involved getting all sorts of
approvals and reviews. Going through that process was more
time-consuming than I would like, and it has put me off from doing
further experiments of a similar nature. However, this means that the
decisions I make are going to be less data driven and more guesswork,
which is not good for obvious reasons.

What I would like to see is a simplified process for telemetry
experiments on Nightly, making it easier to flip a pref on 50% of the
population for a week or two and get some useful data out of it. It
seems to me that many of the approvals (QA, RelMan, Legal, Product)
should not really be needed for this kind of simple temporary
pref-flip, assuming the necessary data collection mechanisms are
already in the code. Does anybody have any objections to this, or have
other suggestions on how to streamline this process a bit more?

To be clear, I'm not suggesting we do away with these approvals
entirely, I just want to see more nuance in the process to determine
when they are *really* required, so that they don't slow us down
otherwise.

Cheers,
kats

[1] https://wiki.mozilla.org/Telemetry/Experiments
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

On Wed, Apr 20, 2016 at 10:26 AM, Benjamin Smedberg
 wrote:
> The goal of this is for experiments to be fairly lightweight.
>
> Can you talk about where the problems were? The only signoffs that are
> currently required are code review (no surprise there) and
> acknowledgement from a release driver.

This sounds reasonable, but the page at
https://wiki.mozilla.org/Telemetry/Experiments (taken at face value,
which is what I did as it was my first foray into this) indicates
otherwise. Perhaps most of my issues could be resolved just by
updating the documentation on that page. For example, it says "Product
approval is required to run an experiment." and is unclear about what
is "user-facing" vs not. It also says to talk to you *before* building
an experiment, which I did (bug 1251052 comment 1), only to then find
out that step was not necessary, so that was extra unnecessary
latency. The doc also says "QA should verify the experience on the
staging server", so I went through that process - it was almost no
work on my part since QA had a template for it already but it still
took nonzero time. The addon signing step is also not yet automated,
as far as I could tell, even though the bug referenced in the doc is
resolved fixed, so that adds an additional dependency and round-trip
to somebody who can sign it.

> For pref flips in particular, we've talked about extending the
> experiment system so that you don't have to write an addon at all:
> that you can just specify pref values in the experiment manifest. That
> would require engineering work and a little bit of new signing work
> that is currently not planned; but if somebody wants to do that work,
> I would be willing to mentor.

This sounds great, and would be really nice. If it's not a huge amount
of work I would be willing to take this on. Is there a bug on file for
it?

> Data review is required only if an experiment collects new data. My
> goal is for this to be fast and straightforward, but IIRC it wasn't
> necessary at all for your recent experiment. There is no legal review
> required for experiments unless I raise a question during data review.

Again, the wiki page should state this more explicitly, for the
benefit of people who are doing an experiment for the first time.

> There is no explicit QA "approval" process required: clearly we don't
> want to ship broken code, so we should use normal good judgement about
> how to test each particular experiment, but that should not be a
> high-process thing by default.

Ditto, wiki page should be clarified. I'm happy to go and update the
page to reflect what you've said here, provided you're willing to
review my changes to make sure I don't go overboard :)

Cheers,
kats

> On Tue, Apr 19, 2016 at 4:43 PM, Kartikaya Gupta  wrote:
>> (Cross-posted to dev-platform and release-management)
>>
>> Hi all,
>>
>> Not too long ago I ran a telemetry experiment [1] to figure out how to
>> tune some of our code to get the best in-the-wild behaviour. While I
>> got the data I wanted, I found the process of getting the experiment
>> going to be very heavyweight as it involved getting all sorts of
>> approvals and reviews. Going through that process was more
>> time-consuming than I would like, and it has put me off from doing
>> further experiments of a similar nature. However, this means that the
>> decisions I make are going to be less data driven and more guesswork,
>> which is not good for obvious reasons.
>>
>> What I would like to see is a simplified process for telemetry
>> experiments on Nightly, making it easier to flip a pref on 50% of the
>> population for a week or two and get some useful data out of it. It
>> seems to me that many of the approvals (QA, RelMan, Legal, Product)
>> should not really be needed for this kind of simple temporary
>> pref-flip, assuming the necessary data collection mechanisms are
>> already in the code. Does anybody have any objections to this, or have
>> other suggestions on how to streamline this process a bit more?
>>
>> To be clear, I'm not suggesting we do away with these approvals
>> entirely, I just want to see more nuance in the process to determine
>> when they are *really* required, so that they don't slow us down
>> otherwise.
>>
>> Cheers,
>> kats
>>
>> [1] https://wiki.mozilla.org/Telemetry/Experiments
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Kartikaya Gupta]

Running that mach try command with the additional --no-push argument
produces this mouthful:

try: -b do -p linux64 -u
crashtest,crashtest-e10s,mochitest-1,mochitest-browser-chrome-1,mochitest-e10s-1,mochitest-e10s-browser-chrome-1,mochitest-o,reftest,reftest-e10s,xpcshell
-t none --try-test-paths browser-chrome:dom chrome:dom crashtest:dom
mochitest:dom reftest:dom xpcshell:dom

On Tue, Apr 26, 2016 at 4:04 PM, Gijs Kruitbosch
 wrote:
> On 26/04/2016 14:01, James Graham wrote:
>>
>> Based on a conversation yesterday, it seems that the features of |mach
>> try| are not well known. In particular it allows running only a subset
>> of tests in cases that you are doing an experimental push that you
>> expect to affect mainly one area of the code. For example:
>>
>> mach try -b do -p linux64 dom
>
>
> What is the equivalent try syntax and how do I generate it from/in/with
> mozreview, which is generally how I push to try these days?
>
> ~ Gijs
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: "passive" option for AddEventListenerOptions

[Kartikaya Gupta]

Summary: Authors can declare in their addEventListener call that the
listener will not be calling preventDefault() on the event. This
unlocks certain performance optimizations.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266066

Link to standard:
https://dom.spec.whatwg.org/#dom-addeventlisteneroptions-passive -
note that this intent email is specifically about the "passive" flag;
the AddEventListenerOptions dictionary and addEventListener
modifications were already implemented in bug 1266194. I don't recall
seeing an intent email for that but maybe I missed it.
There is also an explainer doc at
https://github.com/WICG/EventListenerOptions which might be easier to
read for those already familiar with DOM events.

Platform coverage: all platforms

Estimated or target release: Hoping to get it in Firefox 49. I wrote
the patches today (they were pretty small) hence combining the intent
to implement and ship into this email rather than sending two separate
emails.

Preference behind which this will be implemented: none at the moment

Other browsers: See
https://github.com/WICG/EventListenerOptions#status-of-implementations
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Kartikaya Gupta]

In general developers should probably default to marking their
listeners as passive, unless their listeners are actually going to
call preventDefault(). We don't have a console log for saying "use a
passive listener", no. We can easily detect listeners that are not
marked passive and that are impacting scrolling latency (for example),
but it's impossible to tell with 100% accuracy if those listeners
*should* be marked passive or not. Some of those listeners are
probably legitimately not passive, because they do call
preventDefault() under some conditions - but we can't know that until
those conditions occur and preventDefault() is called.

Cheers,
kats

On Thu, May 5, 2016 at 3:21 PM, Justin Dolske  wrote:
> How will a developer know when it would be worthwhile to mark their event
> listener as passive? Do we perhaps log something to the console?
>
> Justin
>
> On Wed, May 4, 2016 at 3:19 PM, Kartikaya Gupta  wrote:
>>
>> Summary: Authors can declare in their addEventListener call that the
>> listener will not be calling preventDefault() on the event. This
>> unlocks certain performance optimizations.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1266066
>>
>> Link to standard:
>> https://dom.spec.whatwg.org/#dom-addeventlisteneroptions-passive -
>> note that this intent email is specifically about the "passive" flag;
>> the AddEventListenerOptions dictionary and addEventListener
>> modifications were already implemented in bug 1266194. I don't recall
>> seeing an intent email for that but maybe I missed it.
>> There is also an explainer doc at
>> https://github.com/WICG/EventListenerOptions which might be easier to
>> read for those already familiar with DOM events.
>>
>> Platform coverage: all platforms
>>
>> Estimated or target release: Hoping to get it in Firefox 49. I wrote
>> the patches today (they were pretty small) hence combining the intent
>> to implement and ship into this email rather than sending two separate
>> emails.
>>
>> Preference behind which this will be implemented: none at the moment
>>
>> Other browsers: See
>> https://github.com/WICG/EventListenerOptions#status-of-implementations
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

[Kartikaya Gupta]

Correct, the preventDefault() is ignored from a passive listener, and
we will probably log a warning to the console (I have a patch up for
review that does that, let's see what smaug says).

On Fri, May 6, 2016 at 1:01 AM, Anne van Kesteren  wrote:
> On Fri, May 6, 2016 at 4:43 AM, Eric Shepherd  wrote:
>> What happens if the developer specifies passive yet calls
>> preventDefault() anyway?
>
> That's a no-op per https://dom.spec.whatwg.org/#dom-event-preventdefault.
>
>
> --
> https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

Just to close the loop on this, I went ahead and updated the wiki
pages at [1] and [2] to reflect that some parts of the process are
more optional than they originally seemed. I also tried to generally
make the documentation simpler to follow and less
redundant/contradictory. Finally, I filed bug 1271440 for the missing
piece to allow developers to self-sign their experiment addons.

Hopefully these changes will make it easier to build and deploy
experiments in the future.

Cheers,
kats

On Wed, Apr 20, 2016 at 3:31 PM, Jared Hirsch <6...@mozilla.com> wrote:
> Hi all,
>
> I wrote a telemetry experiment last year[1], and I also found the process
> challenging to navigate.
>
> I found that many important details were undocumented, but were mentioned in
> review comments, so I added what I could to the telemetry experiment wiki
> page and to MDN.
>
> My experiment gathered new data, and sent it to a new, one-off server
> endpoint. This definitely required more discussion than the typical
> experiment. That said, I do think there are ways the process could be
> improved for all experiments.
>
> Here are a few suggestions for improving the current process:
> - document how to use Experiments.jsm on MDN
> - document the schema of the Telemetry Experiment-specific manifest.json
> file
> - write and maintain at least one up-to-date, thoroughly commented example
> experiment
> - merge (parts of) the telex QA page[2] into the main page (the link is
> buried in the main page)
> - update and possibly merge the code docs[3] into the main wiki page
>
> To expand on the last bullet point: the code docs suggest using a special
> python build script to assemble the final .xpi, but that's no longer
> accurate, as experiments now need to be signed. Further, each experiment has
> to be *manually* signed, because AMO signing tools will not auto-sign an
> add-on with the special telex emType. A bug has been filed[4] to enable
> auto-signing for experiments, but it hasn't moved since November. Might be
> worth pushing on it.
>
> Each of these missing pieces makes shipping an experiment a little bit
> harder than it has to be. Adding them all up, the process as a whole can
> seem difficult for a first-time experiment author (at least, it did for me
> and evidently for Kats as well).
>
> I hope these suggestions are helpful.
>
> Cheers,
>
> Jared
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1174937
> [2] https://wiki.mozilla.org/QA/Telemetry
> [3]
> http://hg.mozilla.org/webtools/telemetry-experiment-server/file/tip/README.rst
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1220097
>
> On Wed, Apr 20, 2016 at 8:05 AM, Kartikaya Gupta  wrote:
>>
>> On Wed, Apr 20, 2016 at 10:26 AM, Benjamin Smedberg
>>  wrote:
>> > The goal of this is for experiments to be fairly lightweight.
>> >
>> > Can you talk about where the problems were? The only signoffs that are
>> > currently required are code review (no surprise there) and
>> > acknowledgement from a release driver.
>>
>> This sounds reasonable, but the page at
>> https://wiki.mozilla.org/Telemetry/Experiments (taken at face value,
>> which is what I did as it was my first foray into this) indicates
>> otherwise. Perhaps most of my issues could be resolved just by
>> updating the documentation on that page. For example, it says "Product
>> approval is required to run an experiment." and is unclear about what
>> is "user-facing" vs not. It also says to talk to you *before* building
>> an experiment, which I did (bug 1251052 comment 1), only to then find
>> out that step was not necessary, so that was extra unnecessary
>> latency. The doc also says "QA should verify the experience on the
>> staging server", so I went through that process - it was almost no
>> work on my part since QA had a template for it already but it still
>> took nonzero time. The addon signing step is also not yet automated,
>> as far as I could tell, even though the bug referenced in the doc is
>> resolved fixed, so that adds an additional dependency and round-trip
>> to somebody who can sign it.
>>
>> > For pref flips in particular, we've talked about extending the
>> > experiment system so that you don't have to write an addon at all:
>> > that you can just specify pref values in the experiment manifest. That
>> > would require engineering work and a little bit of new signing work
>> > that is currently not planned; but if somebody wants to do that work,
>> > I would be willing to mentor.
>>
>> This sounds great, and would be really nice. If it's not a hu

Re: Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

err [1] is https://wiki.mozilla.org/Telemetry/Experiments and [2] is
https://wiki.mozilla.org/QA/Telemetry/Developing_a_Telemetry_Experiment
:)

On Tue, May 10, 2016 at 10:53 AM, Kartikaya Gupta  wrote:
> Just to close the loop on this, I went ahead and updated the wiki
> pages at [1] and [2] to reflect that some parts of the process are
> more optional than they originally seemed. I also tried to generally
> make the documentation simpler to follow and less
> redundant/contradictory. Finally, I filed bug 1271440 for the missing
> piece to allow developers to self-sign their experiment addons.
>
> Hopefully these changes will make it easier to build and deploy
> experiments in the future.
>
> Cheers,
> kats
>
> On Wed, Apr 20, 2016 at 3:31 PM, Jared Hirsch <6...@mozilla.com> wrote:
>> Hi all,
>>
>> I wrote a telemetry experiment last year[1], and I also found the process
>> challenging to navigate.
>>
>> I found that many important details were undocumented, but were mentioned in
>> review comments, so I added what I could to the telemetry experiment wiki
>> page and to MDN.
>>
>> My experiment gathered new data, and sent it to a new, one-off server
>> endpoint. This definitely required more discussion than the typical
>> experiment. That said, I do think there are ways the process could be
>> improved for all experiments.
>>
>> Here are a few suggestions for improving the current process:
>> - document how to use Experiments.jsm on MDN
>> - document the schema of the Telemetry Experiment-specific manifest.json
>> file
>> - write and maintain at least one up-to-date, thoroughly commented example
>> experiment
>> - merge (parts of) the telex QA page[2] into the main page (the link is
>> buried in the main page)
>> - update and possibly merge the code docs[3] into the main wiki page
>>
>> To expand on the last bullet point: the code docs suggest using a special
>> python build script to assemble the final .xpi, but that's no longer
>> accurate, as experiments now need to be signed. Further, each experiment has
>> to be *manually* signed, because AMO signing tools will not auto-sign an
>> add-on with the special telex emType. A bug has been filed[4] to enable
>> auto-signing for experiments, but it hasn't moved since November. Might be
>> worth pushing on it.
>>
>> Each of these missing pieces makes shipping an experiment a little bit
>> harder than it has to be. Adding them all up, the process as a whole can
>> seem difficult for a first-time experiment author (at least, it did for me
>> and evidently for Kats as well).
>>
>> I hope these suggestions are helpful.
>>
>> Cheers,
>>
>> Jared
>>
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1174937
>> [2] https://wiki.mozilla.org/QA/Telemetry
>> [3]
>> http://hg.mozilla.org/webtools/telemetry-experiment-server/file/tip/README.rst
>> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1220097
>>
>> On Wed, Apr 20, 2016 at 8:05 AM, Kartikaya Gupta  wrote:
>>>
>>> On Wed, Apr 20, 2016 at 10:26 AM, Benjamin Smedberg
>>>  wrote:
>>> > The goal of this is for experiments to be fairly lightweight.
>>> >
>>> > Can you talk about where the problems were? The only signoffs that are
>>> > currently required are code review (no surprise there) and
>>> > acknowledgement from a release driver.
>>>
>>> This sounds reasonable, but the page at
>>> https://wiki.mozilla.org/Telemetry/Experiments (taken at face value,
>>> which is what I did as it was my first foray into this) indicates
>>> otherwise. Perhaps most of my issues could be resolved just by
>>> updating the documentation on that page. For example, it says "Product
>>> approval is required to run an experiment." and is unclear about what
>>> is "user-facing" vs not. It also says to talk to you *before* building
>>> an experiment, which I did (bug 1251052 comment 1), only to then find
>>> out that step was not necessary, so that was extra unnecessary
>>> latency. The doc also says "QA should verify the experience on the
>>> staging server", so I went through that process - it was almost no
>>> work on my part since QA had a template for it already but it still
>>> took nonzero time. The addon signing step is also not yet automated,
>>> as far as I could tell, even though the bug referenced in the doc is
>>> resolved fixed, so that adds an additional dependency and round-trip
>>> to somebod

Re: FF49a1: Page load of jumping points doesn't work like it should in Wikipedia

[Kartikaya Gupta]

Note that this might get fixed in chrome with their new "scroll
anchoring" feature -
https://developers.google.com/web/updates/2016/04/scroll-anchoring?hl=en

kats

On Fri, May 20, 2016 at 12:15 PM, Adam Roach  wrote:
> On 5/20/16 10:13, Gijs Kruitbosch wrote:
>>
>> On 20/05/2016 16:11, Tobias B. Besemer wrote:
>>>
>>> Plz open e.g. this URL:
>>>
>>> https://en.wikipedia.org/wiki/Microsoft_Windows#Alternative_implementations
>>>
>>> FF49a1 loads the page, jumps to "Alternative implementations", stays
>>> there for 1-2 sec and then go ~1 screen-high (page) down.
>>>
>>> Can someone very this bug?
>>
>>
>> The same thing happens in Chrome, so it seems like it's more likely to be
>> an issue with Wikipedia.
>
>
> The fact that turning JavaScript off prevents this behavior would certainly
> seem to support that supposition.
>
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All about crashes

[Kartikaya Gupta]

On Wed, May 25, 2016 at 9:45 PM, Nicholas Nethercote
 wrote:
> On Wed, May 25, 2016 at 6:58 AM, Lawrence Mandel  wrote:
>> "Crashes are caused by defects"
>>
>> Reading this I think it implies defects in Firefox. This is not always the
>> case. Crashes are also the result of interactions with third party software.
>> Both that that we designed for (like NPAPI plug-ins) and that we didn't (AV,
>> malware), which you mention lower down in the doc.
>
> Fair enough. I've modified my terminology. I now talk about crash
> "causes" as the most generic category, and reserve "defects" for
> erronous code and hardware.
>
> 
> In general it's good to be careful with terminology when dealing with
> bugs and crashes, because it can help clarify things. E.g. when
> talking about buggy code, there are three stages for a "bug" to
> manifest:
>
> - Erroneous code. When executed, it can (but doesn't necessarily) lead to...
> - Erroneous runtime state. This can (but doesn't necessarily) lead to...
> - Erronous runtime behaviour. This includes crashes, but also other things.
>
> At times "bug" and "buggy" are used to refer to all three. I tend to
> use "defect" for erroneous code. People sometimes use "error" or
> "fault" for erroneous behaviour. Erroneous runtime state is often
> overlooked as a separate category, and the only specific term I've
> heard for it is "infection" which I don't like much.
> 
>

I realize this is bikeshed-y, but what I learnt in school (and what
the SWEBOK [1] corroborates, on page 84 of the PDF version) is that
"fault" refers to erroneous code, and "failure" refers to the
erroneous runtime behavior. I concur that I've never heard of a
specific term for erroneous runtime state.

Quote from the SWEBOK:

"Many terms are used in the software engineering literature to
describe a malfunction: notably fault, failure, and error, among
others. This terminology is precisely defined in [3, c2]. It is
essential to clearly distinguish between the cause of a malfunction
(for which the term fault will be used here) and an undesired effect
observed in the system’s delivered service (which will be called a
failure). Indeed there may well be faults in the software that never
manifest themselves as failures (see Theoretical and Practical
Limitations of Testing in section 1.2, Key Issues). Thus testing can
reveal failures, but it is the faults that can and must be removed
[3]. The more generic term defect can be used to refer to either a
fault or a failure, when the distinction is not important [3]."

[1] https://www.computer.org/web/swebok/v3

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How badly out of date is this?

[Kartikaya Gupta]

Or make the warning a fixed-position item, so it's on-screen
regardless of where on the page you are.

On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye  wrote:
> On 2016-06-01 5:02 AM, L. David Baron wrote:
>>
>>
>> So I tend to think it's worth keeping, but with a preface that
>> clearly labels it as historical and no longer good practice, and
>> perhaps with an appendix pointing to the current practices.
>
>
> Hey, Sheppy - Should we make a practice of stripping anchor links from
> historical/outdated/archived documentation? On a few occasions I've had
> links drop me into the middle of a document, skipping over the big red
> warning at the top saying "this is old, don't do any of this". I might be
> alone in this, but I suspect I'm not the only person who's lost time because
> of it.
>
>
> - mhoye
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The Whiteboard Tag Amnesty

[Kartikaya Gupta]

What happens after June 24? Is the whiteboard field going to be removed?

On Wed, Jun 8, 2016 at 4:32 PM, Emma Humphries  wrote:
> tl;dr -- nominate whiteboard tags you want converted to keywords. Do it by
> 24 June 2016.
>
> We have a love-hate relationship with the whiteboard field in bugzilla. On
> one hand, we can add team-specific meta data to a bug. On the other hand,
> it's not a indexed field or a real tag system, making it hard to parse,
> search, and update.
>
> But creating keywords is a hassle since you have to request them.
>
> The long term solution is to turn whiteboard into proper tag system, but
> the Bugzilla Team's offering to help with some bulk conversion of
> whiteboard tags your teams use into keywords.
>
> To participate:
>
> 1. Create a Bug in the bugzilla.mozilla.org::Administration component for each
> whiteboard tag you want to convert.
>
> 2. The bug's description should have the old keyword, the new keyword you
> want to replace it with, and the description of this new keyword which will
> appear in the online help.
>
> 3. Make sure your keyword doesn't conflict with existing keywords, so be
> prepared to rename it. If your keyword is semantically similar to an
> existing keyword or other existing bugzilla field we'll talk you about a
> mass change to your bugs.
>
> 4. Make the parent bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1279022,
> depend on your new bug.
>
> 5. CC Emma Humphries on the bug
>
> We will turn your whiteboard tag into a keyword and remove your old tag
> from the whiteboard tags, so make sure your dashboards and other tools that
> consume Bugzilla's API are updated to account for this.
>
> Please submit your whiteboard fields to convert by Friday 24 June 2016.
>
> Cheers,
>
> Emma Humphries
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage for Component Leads

[Kartikaya Gupta]

The wiki says everything from July 1 onwards should be triaged, but
the triage-center tool produces bugzilla links from June 1 onwards
(when you select the "no priority decision" link). Is this
intentional, or just a mix-up?

On Thu, Jun 16, 2016 at 5:17 PM, Emma Humphries  wrote:
> This afternoon I introduced the new triage process we've developed for bugs
> in Firefox-related components.
>
> My presentation is at
> https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing
>
> The guide to the process is on the Mozilla wiki:
> https://wiki.mozilla.org/Bugmasters/Process/Triage
>
> If you are on this list,
> https://wiki.mozilla.org/Bugmasters/Project/Bug_Handling/Triage_Leads, you
> are on the hook to make decisions on bugs in the component. And I'll be
> following up with you over the next two weeks to see how you are doing, and
> what questions you have about this process.
>
> After I return from London, I'll also put together a short video for Air
> Mozilla introducing the process.
>
> -- Emma
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to enable: touch-action (on Nightly)

[Kartikaya Gupta]

In the next few days, I intend to enable support for touch-action on
Nightly (#ifdef NIGHTLY_BUILD), for all platforms. The implementation
is behind the layout.css.touch_action.enabled property. touch-action
is spec'd as part of the Pointer Events spec [1] - the rest of the
spec is currently being implemented in Firefox, but is not yet ready
to be enabled. The touch-action CSS property is relatively independent
of the rest, and can be enabled separately. The patch to turn it on is
in bug 1029631, and the dependency tree has various implementation
bugs if you go deep enough.

Note that turning on touch-action will be detectable by web content on
all platforms (e.g. by checking for the existence of
getComputedStyle(document.body).touchAction). However, the
implementation only does something on platforms/configurations where
we have touch event support. Those platforms are: (1) Android, (2)
Linux with e10s and MOZ_USE_XINPUT2=1 in the environment, (3) Windows
Nightly with e10s enabled [2].

Other UAs have already mostly implemented and shipped touch-action
support [3]. I don't expect much in the way of interop or webcompat
issues with this change, but please file bugs if you notice something
that might be caused by this. Later this month, I will be meeting with
other browser vendors and hammer out any issues that come up, and I
expect to let this ride the trains in Fx 50 or (more likely) 51, along
with general touch event support on Windows.

Cheers,
kats

[1] 
https://www.w3.org/TR/pointerevents/#declaring-candidate-regions-for-default-touch-behaviors
[2] Since touch-enabled Windows devices trigger accessibility
activation, they run with e10s disabled by default, even on Nightly.
You have to set browser.tabs.remote.force-enable=true to actually get
e10s on these devices. The plan is to make e10s accessibility-friendly
in 51 or 52 at which point this caveat goes away.
[3] http://caniuse.com/#search=touch-action
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: TouchEvents (Windows), touch-action (all platforms), accessible caret

[Kartikaya Gupta]

In Firefox 52 I intend to ship support for TouchEvents on Windows
e10s. TouchEvent support has already been enabled on Android for a
long time and has been enabled on Linux e10s as well (if you have
MOZ_USE_XINPUT2=1 in your environment). The pref that controls this
feature is dom.w3c_touch_events.enabled. The pref has been enabled on
Nightly for a number of months, and bug 1244402 is now letting it ride
the trains. Chrome/Opera and Safari on iOS all support Touch Events,
and it is specced at [1].

Additionally, I also intend to ship support for the CSS touch-action
property, which is defined in the Pointer Events spec [2]. Note that
our support for touch-action currently does NOT include support for
the Pointer Events Level 2 property values such as pan-up/pan-down.
Touch-action will be supported on all platforms that support touch
input (i.e. Android, Linux e10s with MOZ_USE_XINPUT2=1, and Windows
e10s). The pref that controls this feature is
layout.css.touch_action.enabled. This pref has also been enabled on
Nightly for a number of months now and bug 1244402 is letting it ride
the trains. Touch-action is supported in IE/Edge, Chrome/Opera, and
partly in Safari.

Note also that along with enabling these features, touch scrolling on
Windows e10s will now be handled natively by APZ in the compositor
rather than being converted into wheel events by the OS, which should
enhance scrolling responsiveness and control. To round out touch
support, we are also enabling the "accessible caret" for text
selection on desktop platforms where TouchEvents are supported. This
allows the user to manipulate text selection using the touch-friendly
carets you already see in Firefox for Android. This is controlled by
the pref layout.accessiblecaret.enabled_on_touch. As with the
web-facing features, these have been enabled on Nightly builds for a
while and now are going to ride the trains.

Aside 1: on current Nightly, you *still* need to set
browser.tabs.remote.force-enable to true on Windows touch devices to
get e10s enabled. This is due to the instability caused by some
accessibility code, but the plan is to have those bugs fixed and that
restriction eliminated in Firefox 52 as well, hopefully within the
next week or two.

Aside 2: sorry for lumping all these things in one email, but they're
all related and mostly need to ship together.

Cheers,
kats

[1] https://www.w3.org/TR/touch-events/
[2] https://www.w3.org/TR/pointerevents/ (section 9)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding Rust code to Gecko, now documented

[Kartikaya Gupta]

I'm actually trying to debug a rust issue right now and have some
questions. I've done the |mach vendor rust| step and got all the
vendored crates. Now let's say that in one of the dependencies (the
'cmake' crate in my case) there's some sort of behaviour that I'd like
to investigate/debug. If I edit the third_party/rust/cmake/src/lib.rs
in-place, the build fails because of a hash mismatch. The error
suggests forking the repo and using [replace] instead - so I tried do
that by copying the cmake folder to third_party/rust/cmake-fork and
putting a [replace] section in toolkit/library/rust/Cargo.toml to
point to it. However if I do that the force-cargo-build step in the
build fails saying the lock file needs updating but --locked was
passed.

Am I on the right track here, or is there some other easier way to
modify one of the vendored crates for local debugging?


On Wed, Nov 9, 2016 at 6:20 AM, Ted Mielczarek  wrote:
> I recently wrote some documentation on how to add Rust code to Gecko:
> http://gecko.readthedocs.io/en/latest/build/buildsystem/rust.html
>
> It should be fairly straightforward for most use cases (thanks to Nathan
> Froyd for doing the lion's share of the work to make it so), but if
> there's anything that's unclear feel free to ask for clarification.
>
> -Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Adding Rust code to Gecko, now documented

[Kartikaya Gupta]

On Wed, Nov 9, 2016 at 11:51 AM, Ralph Giles  wrote:
> On Wed, Nov 9, 2016 at 8:41 AM, Kartikaya Gupta  wrote:
>
>> If I edit the third_party/rust/cmake/src/lib.rs
>> in-place, the build fails because of a hash mismatch.
>
> Interesting! This is supposed to happen as a check against corruption
> and/or non-reproducible builds, but I can't reproduce by modifying
> third_party/rust/byteorder/src/lib.rs. Is this the full gecko `mach
> build` or a local `cargo build` of the crate you're working on?

This is with a full gecko `mach build`. And it's weird - a couple of
times when I modified the lib.rs and ran the build it didn't error
out, but it also didn't pick up my changes to lib.rs. So maybe it's
short-circuiting the rebuild in some cases?

>> However if I do that the force-cargo-build step in the
>> build fails saying the lock file needs updating but --locked was
>> passed.
>
> Try running 'cargo update' in toolkit/library/rust

I did this, and it updated the Cargo.lock file, but it produces the
same hash mismatch error, because the modified lib.rs in my cmake-fork
folder doesn't match the hash stored in the
cmake-fork/.cargo-checksum.json file. Removing that
.cargo-checksum.json file from the fork doesn't work either, since the
build requires it to be there. In the end I just manually modified the
checksum file to have the new hash (which thankfully the error message
provided).

kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Async scrollbar dragging enabled on Nightly

[Kartikaya Gupta]

On Wed, Dec 21, 2016 at 6:19 AM, Gervase Markham  wrote:
> Why do we paint a checkerboard

We don't actually paint a checkerboard pattern.

> rather than the default single background
> colour of the page?

This is what we do. It's still *called* checkerboarding though. The
behaviour has changed, the name has not.

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform