Heads up: small Fission experiment starting in 88 Beta

[Chris Peterson]

The Fission team plans to start a small Fission experiment in 88 Beta, 
which will likely run through 89 Beta. The experiment will be just 10% 
(5% Fission + 5% control).


I know 89 is the Proton MR1 release. I've confirmed with the Proton PMs 
that they do not mind Fission running an experiment during 89 Beta, as 
long as we are just continuing the same experiment we started in 88 Beta 
and we keep the experiment at 10%.


Our Fission Nightly experiment has been running for months without any 
major stability or perf issues. We just increased our Fission Nightly 
experiment to 100% (50% Fission + 50% control) during 88 Nightly.


If you have questions or concerns, please email me or drop by the 
#fission channel in Matrix or Slack.


chris


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

Re: C++ PSA: Use [[nodiscard]] instead of MOZ_MUST_USE

[Chris Peterson]

Bug 1571631 has landed. The `MOZ_MUST_USE` macro has been removed and 
all uses have been replaced with C++17's `[[nodiscard]]` function 
attribute. Use [[nodiscard]] instead of MOZ_MUST_USE.


One caveat: unlike MOZ_MUST_USE, [[nodiscard]] must precede all of a 
function declaration's declaration specifiers (like static, extern, 
inline, or virtual):


- static inline MOZ_MUST_USE nsresult SomeFunction();
+ [[nodiscard]] static inline nsresult SomeFunction();

Next steps:

1. Replace MOZ_MUST_USE_TYPE type declarations with [[nodiscard]]. Bug 
1628542


2. Consider removing `mozilla::Unused`, replacing over 3000 uses of 
`Unused << SomeFunction()` with a more idiomatic `(void) SomeFunction()` 
cast. mozilla::Unused was a workaround for the fact that gcc didn't 
allow MOZ_MUST_USE (`__attribute__((warn_unused_result))`) warnings to 
be suppressed with a void cast. Because this change would touch so many 
files, it's probably not worth the trouble. Bug 1628542



On 12/21/2020 4:20 PM, Chris Peterson wrote:
Now that Firefox is compiled as C++17 (bug 1560664), you can use C++17's 
[[nodiscard]] attribute [1] instead of the MOZ_MUST_USE macro (defined 
using clang and gcc's non-standard __attribute__((warn_unused_result))).


I have been slowly replacing MOZ_MUST_USE with [[nodiscard]] in my free 
time and hope to eventually remove the MOZ_MUST_USE definition itself. 
That is meta bug 1571631.


In the meantime, please:

1. Avoid adding more uses of MOZ_MUST_USE. Use [[nodiscard]].

2. Consider making more functions use [[nodiscard]] when writing or 
reviewing new code. Functions that return errors as nsresult or bool are 
probably good candidates for [[nodiscard]].


(I looked at adding [[nodiscard]] to the nsresult type definition, but 
the results were too noisy.)


One caveat: the [[nodiscard]] attribute must precede all of a function 
declaration's declaration specifiers (like static, extern, inline, or 
virtual). The __attribute__((warn_unused_result)) attribute (and thus 
MOZ_MUST_USE) does not have this order restriction.


- static inline MOZ_MUST_USE nsresult SomeFunction();
+ [[nodiscard]] static inline nsresult SomeFunction();

Once __attribute__((warn_unused_result)) has been replaced with 
[[nodiscard]], we can also remove mozilla::Unused, replacing `Unused <<` 
with a more idiomatic `(void)` cast (bug 1628542).


[[nodiscard]] can also be applied to types, so we may be able to replace 
our custom MOZ_MUST_USE_TYPE clang plugin with [[nodiscard]].


[1] https://en.cppreference.com/w/cpp/language/attributes/nodiscard


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

Re: User-facing benefits from UA exposure of Android version and Linux CPU architecture

[Chris Peterson]

On 2/18/2021 3:51 AM, Henri Sivonen wrote:

As for the CPU architecture on Linux, on Mac and Windows we don't
expose aarch64 separately. (On Windows, consistent with Edge, aarch64
looks like x86. On Mac, aarch64 looks like x86_64 which itself doesn't
differ from what x86 looked like.)


As an alternative to removing the CPU architecture from the UA string, 
Safari on iPhone literally uses "CPU" as a placeholder:


Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) ...

I don't know if Apple's iOS 1.0 team discovered a broken UA parsing 
script that expected a CPU token or if they inserted the CPU placeholder 
just to be prudent. Safari on iPadOS (and macOS aarch64, as you noted) 
still uses the "Intel" desktop UA.



The software download situation for each desktop platform is
different: On Windows, an x86 stub installer can decide whether to
install x86, x86_64, or aarch64 app. On Mac, Universal Binaries make
it irrelevant to know the CPU architecture at the app download time.
On Linux, downloads outside the distro's package manager typically
involve the user having to choose from various options anyway due to
tarball vs. .deb vs. .rpm vs. Flatpak vs. Snap, etc. OTOH, unlike on
Windows and Mac, x86 or x86_64 emulation isn't typically automatically
ready to work on Linux.


Another alternative is to remove the CPU architecture from the 
User-Agent HTTP header (to reduce servers' passive fingerprinting), but 
still expose it in the navigator.userAgent and navigator.platform APIs. 
But this header/API inconsistency might confuse sites (e.g. like 
polyfill.io  that serves different JS to different UAs).


I know the VLC download page dynamically detects 32- and 64-bit Windows:

https://www.videolan.org/vlc/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

C++ PSA: Use [[nodiscard]] instead of MOZ_MUST_USE

[Chris Peterson]

Now that Firefox is compiled as C++17 (bug 1560664), you can use C++17's 
[[nodiscard]] attribute [1] instead of the MOZ_MUST_USE macro (defined 
using clang and gcc's non-standard __attribute__((warn_unused_result))).


I have been slowly replacing MOZ_MUST_USE with [[nodiscard]] in my free 
time and hope to eventually remove the MOZ_MUST_USE definition itself. 
That is meta bug 1571631.


In the meantime, please:

1. Avoid adding more uses of MOZ_MUST_USE. Use [[nodiscard]].

2. Consider making more functions use [[nodiscard]] when writing or 
reviewing new code. Functions that return errors as nsresult or bool are 
probably good candidates for [[nodiscard]].


(I looked at adding [[nodiscard]] to the nsresult type definition, but 
the results were too noisy.)


One caveat: the [[nodiscard]] attribute must precede all of a function 
declaration's declaration specifiers (like static, extern, inline, or 
virtual). The __attribute__((warn_unused_result)) attribute (and thus 
MOZ_MUST_USE) does not have this order restriction.


- static inline MOZ_MUST_USE nsresult SomeFunction();
+ [[nodiscard]] static inline nsresult SomeFunction();

Once __attribute__((warn_unused_result)) has been replaced with 
[[nodiscard]], we can also remove mozilla::Unused, replacing `Unused <<` 
with a more idiomatic `(void)` cast (bug 1628542).


[[nodiscard]] can also be applied to types, so we may be able to replace 
our custom MOZ_MUST_USE_TYPE clang plugin with [[nodiscard]].


[1] https://en.cppreference.com/w/cpp/language/attributes/nodiscard
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improvement to build times through cleanup of C++ include dependencies

[Chris Peterson]

On 12/14/2020 3:23 AM, Simon Giesecke wrote:

I was using some tools to support this, notably ClangBuildAnalyzer [2] and
include-what-you-use [3]. ClangBuildAnalyzer helped to detect headers that
are expensive to parse throughout the build, and direct efforts to reduce
those specifically. But there remains a long tail of similar things that
can and should be fixed. include-what-you-use helps to identify the headers
from which a file uses declarations to avoid depending on indirectly
included files which might disappear from the include chain by unrelated
changes. These tools are not readymade for everyday use, but I will try to
provide some ideas for using them effectively later on.


Can include-what-you-use be configured as a Phabricator linter to warn 
about new unused header includes before they are checked in?

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

Re: Please don't use functions from ctype.h and strings.h

[Chris Peterson]

On 8/27/2018 7:00 AM, Henri Sivonen wrote:

I think it's worthwhile to have a lint, but regexps are likely to have
false positives, so using clang-tidy is probably better.

A bug is on file:https://bugzilla.mozilla.org/show_bug.cgi?id=1485588

On Mon, Aug 27, 2018 at 4:06 PM, Tom Ritter  wrote:

Is this something worth making a lint over?  It's pretty easy to make
regex-based lints, e.g.

yml-only based lint:
https://searchfox.org/mozilla-central/source/tools/lint/cpp-virtual-final.yml

yml+python for slightly more complicated regexing:
https://searchfox.org/mozilla-central/source/tools/lint/mingw-capitalization.yml
https://searchfox.org/mozilla-central/source/tools/lint/cpp/mingw-capitalization.py



Bug 1642825 recently added a "rejected words" lint. It was intended to 
warn about words like "blacklist" and "whitelist", but dangerous C 
function names could easily be added to the list:


https://searchfox.org/mozilla-central/source/tools/lint/rejected-words.yml

A "good enough" solution that can find real bugs now is preferable to a 
cleaner clang-tidy solution someday, maybe. (The clang-tidy lint bug 
1485588 was filed two years ago.)

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

Reimplementing MOZ_ALWAYS_TRUE() using MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT()

[Chris Peterson]

Heads up:

In 77 Nightly, I plan to reimplement MOZ_ALWAYS_TRUE() using 
MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT(). This is bug 1620152.


MOZ_ALWAYS_TRUE(X) and friends [1] are like MOZ_ASSERT(X), except they 
also evaluate the expression X in release builds. This is useful for 
silencing warnings about unused return values in code that produces side 
effects in release builds, but doesn't need explicit error checking. 
There are currently about 1200 uses of MOZ_ALWAYS_TRUE()/etc in 
mozilla-central.


MOZ_DIAGNOSTIC_ASSERT(X) will MOZ_RELEASE_ASSERT() the expression X in 
release builds of Nightly and DevEdition. This might trigger some new 
crash signatures or spikes in Nightly. MOZ_ALWAYS_TRUE()/etc will still 
evaluate the expression X in release builds of Beta or Release without 
aborting.


If a developer confidently opts for MOZ_ALWAYS_TRUE() instead of 
explicit error handling, the new diagnostic MOZ_ALWAYS_TRUE()/etc will 
give us more confidence that users don't actually hit an unchecked error 
in the wild.


[1]
MOZ_ALWAYS_TRUE
MOZ_ALWAYS_FALSE
MOZ_ALWAYS_SUCCEEDS (alias for MOZ_ALWAYS_TRUE(NS_SUCCEEDED()))
MOZ_ALWAYS_OK (alias for result.isOk())
MOZ_ALWAYS_ERR (alias for result.isErr())
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fission meetings at the Berlin All Hands

[Chris Peterson]

The Fission team will be hosting a few meetings at the Berlin All Hands 
to help Firefox frontend and Gecko engineers convert their code to 
Fission's async APIs.


Step 1: attend the "Introduction to Fission Engineering" presentation to 
get an overview and code examples of Fission:


* Sched: 
https://berlinallhandsjanuary2020.sched.com/event/ZDq3/introduction-to-fission-engineering


* Agenda: 
https://docs.google.com/document/d/10OWQJ-fEb1-sjAXlzBpc8EZloX8lDYFclNTvLaEiHcU/edit


Step 2: drop by the Fission team's office hours for Q or hands-on 
help! Office hours' times and locations:


* Thursday 10:30am - 12:00pm at InterContinental Schoenberg III

* Friday 1:00pm - 3:00pm at InterContinental Charlottenburg II

If you have questions about Fission's plans or meetings, just email me 
or ask in the #fission channel on Slack or Matrix.

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

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

[Chris Peterson]

On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote:

FWIW once in a while I have come across bugs caused by truncation of
integers where someone picked a specific size that was too small also, 
e.g.

storing an offset into a text node in a 16-bit integer.  I think that's
maybe something that's hiding between the lines there, being careful with
that direction also if you pick a type with a specific size to make sure
your type is large enough.


Yep. Recent example: https://bugzilla.mozilla.org/show_bug.cgi?id=1556019 .


If integer truncation bugs are something we're really concerned about, 
clang 8 added a new -Wimplicit-int-conversion (and 
-Wimplicit-float-conversion) warning. Unfortunately, there are a couple 
thousand instances of these warnings in mozilla-central. I don't know if 
fixing them is practical, but they could be selectively enabled (or 
disabled) for individual directories.


https://clang.llvm.org/docs/DiagnosticsReference.html#wimplicit-int-conversion

warning: higher order bits are zeroes after implicit conversion
warning: implicit conversion loses integer precision: A to B

warning: implicit conversion loses floating-point precision: A to B
warning: implicit conversion when assigning computation result loses 
floating-point precision: A to B

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

Re: Using Google styling of #define guards

[Chris Peterson]

On 7/3/2019 11:37 AM, Bryce Seager van Dyk wrote:

I wanted to clarify, and discuss if needed, our styling of #define guards. My 
understanding is that we are now using Google's style in regards to #define 
guards (https://google.github.io/styleguide/cppguide.html#The__define_Guard). I 
believe this would mean for `dom/media/foo/bar.h` I would use a `#define 
DOM_MEDIA_FOO_BAR_H_` style guard.


The Google style guide says:

"The format of the symbol name should be ___H_. ... 
For example, the file foo/src/bar/baz.h in project foo should have the 
following guard: #ifndef FOO_BAR_BAZ_H_"


Would our project prefix be "MOZ_"? The #define guard for 
dom/media/foo/bar.h would then be MOZ_DOM_MEDIA_FOO_BAR_H.

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

Re: Running C++ early in shutdown without an observer

[Chris Peterson]

On 6/7/2019 9:36 AM, Kris Maglione wrote:

On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote:

For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we
have a similar method for running things as soon as we've decided that
the application is going to shut down?

(I know there are observer topics, but I'm trying to avoid having to
create an observer object and to make sure that _it_ gets cleaned up
properly.)


Observers are automatically cleaned up at XPCOM shutdown, so you 
generally don't need to worry too much about them. That said, 
nsIAsyncShutdown is really the way to go when possible. But it currently 
requires an unfortunate amount of boilerplate.


Note that on Android, you may never get an opportunity for a clean 
shutdown because the OS can kill your app at any time.


I don't know what is the recommendation for shutdown activities on 
Android. The GeckoView team has had some recent bugs caused by shutdown 
tasks not running (e.g. committing cached font files or deleting temp 
files). I think these tasks were moved to startup or scheduled to run 
periodically.

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

Re: Remove browser and OS architecture from Firefox's User-Agent string?

[Chris Peterson]

On 5/14/2019 9:53 AM, Tom Ritter wrote:

On Tue, May 14, 2019 at 4:26 PM L. David Baron  wrote:

So I think there's may be value in removing these distinctions from
the User-Agent header we send over HTTP even if they're still
accessible from Javascript (and useful there for sites offering
downloads).

While I would prefer to remove the distinction everywhere; Tor Browser
came to this same conclusion. They send the same OS for all platforms
in the HTTP Header (partially because Web Logs so commonly record this
and partially in principal) but they report the correct OS via
javascript (because we found issues with compatibility (primarily
keyboard shortcuts in things like gdocs.)


Distinguishing between active and passive fingerprinting is a good point.

Gecko could omit platform architecture from the User-Agent header but 
keep it in the navigator.userAgent API. Is returning two different UA 
strings (like Tor) preferable to keeping the Gecko-specific 
navigator.oscpu API?


I'm not convinced of a legitimate use case for web content to simply be 
handed the platform architecture on Linux, Android, or macOS. Web 
content could still try to detect performance characteristics, but the 
detection methods might not work reliably on all CPU models, 
architectures, and operating systems. For example, the ghacks detection 
testing [1] could distinguish Win32 and Win64 Firefox builds, but not 
Win32 or Win64 OS.


The HTML spec says [1] Gecko's navigator.oscpu may return an empty 
string or "a string representing the platform". We could limit 
navigator.oscpu to return:


* empty string "" on Linux, Android, and macOS
* "Windows NT 10.0" for Win32 Firefox (like today)
* "Windows NT 10.0; Win64; x64" for Win64 (like today) and WOW64 Firefox 
(instead of "Windows NT 10.0; WOW64")


and still adhere to the HTML spec. We could then return the same UA 
string in the User-Agent header and navigator.userAgent API while still 
giving websites an easy way to distinguish Win32 and Win64 OS using 
navigator.oscpu.



[1] https://github.com/ghacksuserjs/ghacks-user.js/issues/657
[2] 
https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-oscpu



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

Re: Remove browser and OS architecture from Firefox's User-Agent string?

[Chris Peterson]

On 5/11/2019 8:59 AM, Henri Sivonen wrote:

"Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0"


Would there be significant downsides to hard-coding the Windows
version to "10.0" in order to put Windows 7 and 8.x users in the same
anonymity set with Windows 10 users?

...
> Meanwhile, could we make the system version number "10.14" (or
> whatever is latest at a given point in time) regardless of actual
> version number to put all macOS users in the same anonymity set?
> (Curiously, despite Apple's privacy efforts, Safari exposes the third
> component of the OS version number. Also, it uses underscores instead
> of periods as the separator.)

Firefox spoofs the latest OS versions when the 
privacy.resistFingerprinting pref is enabled (e.g. in Tor). I think 
always spoofing the OS version is worth considering as a follow up task. 
I'd like to limit the scope of this initial proposal just to CPU 
architecture.



> It seems that for privacy reasons, we should claim the latest Android
> version for everyone even if it means introducing the recurring task
> of incrementing the number annually or so.

We've already bumped privacy.resistFingerprinting's spoofed OS versions 
for new ESR versions, so this wouldn't be a burden:


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



Do we have indications if "Linux" is needed for Web compat? According
to 
https://docs.google.com/spreadsheets/d/1I--o6uYWUkBw05IP964Ee2aZCf67P9E3TxpuDawH4_I/edit#gid=0
FreeBSD currently does not say "Linux". (Chrome on Chrome OS does not
say Linux, either, but does say "X11; ".) That is, could "X11; " alone
be sufficient for Web compat? (I'm happy to see that running Firefox
in Wayland mode still says "X11; ". Let's keep it that way!)


I don't know. Trimming the OS is worth considering as a follow up task.


Do we have an idea if distros would counteract Mozilla and restore the
CPU architecture if we removed it? Previous evidence suggests that
distros are willing to split the anonymity set for self-promotional
reasons by adding "; Ubuntu" or "; Fedora". Is there a similar distro
interest in exposing the CPU architecture?


I can try to contact some distro representatives and ask about them 
exposing the CPU architecture.




https://docs.google.com/spreadsheets/d/1I--o6uYWUkBw05IP964Ee2aZCf67P9E3TxpuDawH4_I/edit#gid=0
suggests making Firefox on FreeBSD say "Linux". Are there indications
that the self-promotion interests of FreeBSD wouldn't override privacy
or Web compat benefits of saying "Linux"?


We can probably delegate that decision to the FreeBSD developers. I 
shouldn't have included it because it's beyond the scope of my proposal 
to remove CPU architecture.




I propose no change to the macOS UA string at this time. Removing
"Intel" now would not reduce any fingerprinting entropy (all modern Macs
are x86_64) and might risk confusing some UA string parsers. If AArch64
MacBooks become a real platform, I propose we then remove "Intel" so
x86_64 and AArch64 macOS would have the same UA string:

< "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101
Firefox/66.0"
  > "Mozilla/5.0 (Macintosh; Mac OS X 10.14; rv:66.0) Gecko/20100101
Firefox/66.0".


Or they could have the same UA string by Aarch64 saying "Intel"...


I see that iOS Safari's UA reports "CPU iPhone" where macOS Safari 
reports "Intel Mac OS X". Presumably Apple thought a placeholder UA 
token (like "CPU") was needed instead of just "iPhone". I assume Apple 
would use the same "CPU" placeholder for Safari on a hypothetical 
AArch64 macOS. In the meantime, there's little value in removing "Intel".

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

Re: Remove browser and OS architecture from Firefox's User-Agent string?

[Chris Peterson]

On 5/11/2019 4:11 AM, j.j. wrote:

< "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101
Firefox/66.0"
  > "Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0"

Note that  "navigator.oscpu"  returns  "Windows NT 6.1; Win64; x64"  or 
similar. This needs to change then.



Yes. navigator.oscpu and the UA string share some common code, so they 
would both be fixed to match 32-bit Windows.


btw, navigator.platform has already been fixed to return "Win32" for 
Win32, WOW64, and Win64 Firefox builds (in bug 1472618).


navigator.platform returns:

Browser| Win32 OS | Win64 OS
---+--+-
IE11   | "Win32"  | "Win64"
Chrome | "Win32"  | "Win32"
Edge   | "Win32"  | "Win32" (changed to match Chrome)
Firefox 62 | "Win32"  | "Win64"
Firefox 63 | "Win32"  | "Win32" (changed in bug 1472618)

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

Remove browser and OS architecture from Firefox's User-Agent string?

[Chris Peterson]

Hello, UA string fans! I propose that Firefox's UA string on Windows and 
Linux omit the browser and OS architectures to reduce UA fingerprinting 
entropy (and save a few header bytes).


I have tentative thumbs up from some webcompat and privacy people, but 
as there is no official module owner for User-Agent string at this time, 
I wanted to get some wider feedback here.


The primary use case for including OS architecture (Win32, Win64) and 
version in the UA string is to allow software download sites to offer 
compatible software. A second use case I've heard is for websites to 
workaround platform bugs or serve a page design to match the OS theme, 
but I have not seen real examples of this.


The UA string on Windows and Linux currently reveals both the browser 
and OS architectures:


* 32-bit Firefox on 32-bit OS: "Windows", "Linux i686" or armv7l
* 32-bit Firefox on 64-bit OS: "WOW64", "Linux i686 on x86_64"
* 64-bit Firefox on 64-bit OS: "Win64", "Linux x86_64" or aarch64

I propose that Win64 and WOW64 use the unadorned Windows UA already used 
by Firefox on x86 and AArch64 Windows:


< "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 
Firefox/66.0"

> "Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0"

And that Linux omit the OS architecture entirely (like Firefox on 
Android or always spoof "i686" if an architecture token is needed for UA 
parsing webcompat):


< "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:66.0) Gecko/20100101 
Firefox/66.0"

> "Mozilla/5.0 (X11; Linux; rv:66.0) Gecko/20100101 Firefox/66.0"

If a software download site doesn't see "Win64" or "WOW64" in the UA 
string, it might serve a Win32 x86 executable to a Win64 OS user. The 
x86 executable would still be compatible, just not optimal. (Firefox and 
Chrome don't have this problem because they ship smart stub installers.) 
Linux users are unlikely to download much software from sites that sniff 
their OS architecture, so omitting it should be safe.


If a site *really* wants to detect the client's browser or OS 
architecture, it can use Flash APIs or detect known differences between 
Firefox's 32-bit and 64-bit JavaScript Math functions [1].


If we think allowing software download sites to sniff and serve Win64 
executables is important, we can include the OS architecture but omit 
the browser architecture (i.e. report "Win64" instead of "WOW64"). Sites 
don't need to know whether the user is running a x86 or x86_64 browser 
on their Win64 OS.


I propose no change to the macOS UA string at this time. Removing 
"Intel" now would not reduce any fingerprinting entropy (all modern Macs 
are x86_64) and might risk confusing some UA string parsers. If AArch64 
MacBooks become a real platform, I propose we then remove "Intel" so 
x86_64 and AArch64 macOS would have the same UA string:


< "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 
Firefox/66.0"
> "Mozilla/5.0 (Macintosh; Mac OS X 10.14; rv:66.0) Gecko/20100101 
Firefox/66.0".


Here is a spreadsheet comparing UA strings of different browser and OS 
architectures:


https://docs.google.com/spreadsheets/d/1I--o6uYWUkBw05IP964Ee2aZCf67P9E3TxpuDawH4_I/edit#gid=0


[1] https://github.com/ghacksuserjs/ghacks-user.js/issues/657
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fennec moving to extended support

[Chris Peterson]

On 4/28/2019 12:40 PM, Dirkjan Ochtman wrote:

As a nightly Fennec user, I'd much rather start running Fenix nightlies at
some point soon. Is there any tentative ETA when Fenix nightlies will
become available for dogfooding on the Play Store, with regular updates?


I don't know when Fenix Nightly builds will be available in the Google 
Play Store, but Mozilla's Android Components "Reference Browser" does 
have Nightly builds in the Play Store. Reference Browser is a good way 
to test drive GeckoView performance and compatibility. Fenix reuses a 
lot of Gecko and Android code that first lands in the Reference Browser.


https://github.com/mozilla-mobile/reference-browser/blob/master/README.md#test-channel-on-google-play-store

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

Re: PSA: Min clang / libclang requirement was updated not long ago...

[Chris Peterson]

Seems like mach bootstrap should have a clobber flag so anyone updating 
build tool dependencies can force people to re-run mach bootstrap (and 
save many people frustration).



On 2/26/2019 10:00 AM, David Major wrote:

Does configure warn about this?

The link between this error and needing to bootstrap is not super
clear (and a surprising number of people don't read dev-platform) so
I'm not looking forward to answering the same question in #build for
the rest of the week. :)

On Tue, Feb 26, 2019 at 12:23 PM Emilio Cobos Álvarez  wrote:


... so if you don't use the mozilla-provided libclang (or are using a
very old one), and you see an error like:


error[E0277]: the trait bound

`values::generics::rect::Rect>:
std::convert::From,

Please re-run mach bootstrap, or update your libclang.

Thanks!

  -- Emilio
___
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: Type-based alias analysis and Gecko C++

[Chris Peterson]

On 2/17/2019 11:40 PM, Henri Sivonen wrote:

Out of curiosity: Do we know if WebKit and Chromium compile with or
without strict-aliasing?


Chromium disabled strict aliasing in 2010 [1] and then in 2013 WONTFIX'd 
the bug that would re-enable strict aliasing[2]. The WONTFIX discussion 
[3] reported no big performance improvements (on Dromaeo or Octane) and 
cited Firefox bug comments with similar results (for SunSpider and V8 
benchmarks).


The Firefox test used gcc 4.3 in 2011. Maybe strict aliasing 
optimizations are better with clang in 2019?


[1] 
https://chromium.googlesource.com/chromium/src/+/ecf52cb820c80a600436aca1a5a72533db32b48d


[2] https://bugs.chromium.org/p/chromium/issues/detail?id=32204

[3] 
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/dUebWSEpAR8/xhsispuiNu4J

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

Re: Intent to Implement: css-scroll-anchoring

[Chris Peterson]

This is great news! In a recent study of Fennec's perceived performance, 
users ranked 16 criteria for evaluating mobile browser responsiveness. 
#1 was "Not having the page jump around when scrolling". For a point of 
reference for just how important that is, "Loading a website" was only 
#3. :)


Will scroll anchoring benefit both desktop and mobile content? What is a 
good example website to see the effect of scroll anchoring?



On 2018-11-14 1:09 PM, Ryan Hunt wrote:

Apologies. The target release is 66, while Chrome released this feature in M56.




‐‐‐ Original Message ‐‐‐
On Wednesday, November 14, 2018 3:05 PM, Ryan Hunt  wrote:


Summary:

Scroll anchoring aims to prevent user experience disruptions from content
loading outside the viewport and causing the page to jump around.

Bug: Bug 1305957

Link to standard:

https://drafts.csswg.org/css-scroll-anchoring/

Platform coverage: All platforms

Estimated or target release: 56

Preference behind which this will be implemented: 
layout.scroll-anchoring.enabled

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: No bug

Do other browser engines implement this?

Chrome shipped this in M56.

web-platform-tests:

https://github.com/web-platform-tests/wpt/tree/master/css/css-scroll-anchoring

Is this feature restricted to secure contexts?

No. Scrolling behavior changes aren't restricted to secure contexts.

Thanks,
Ryan





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

Re: Announcing new test platform "Android 7.0 x86"

[Chris Peterson]

On 2018-11-01 3:06 PM, Nicholas Alexander wrote:

Like the existing "Android 4.2" and "Android 4.3" test platforms, these
tests run in an Android emulator running in a docker container (the same
Ubuntu-based image used for linux64 tests).  The new platform runs an x86
emulator using kvm acceleration, enabling tests to run much, much faster
than on the older platforms. As a bonus, the new platform uses Android 7.0
("Nougat", API 24) - more modern, more relevant.


This is incredibly awesome news!  For those not in the know, the reason
this is so noteworthy is that most cloud-based hosts don't expose KVM
acceleration, since it can be a sec concern.  In particular, AWS doesn't
expose KVM to most (all?) instances.  There's an awful lot of plumbing
required to get jobs running in different cloud hosts... but here we are.


Our Android test coverage has been sparse in the past because slow ARM 
emulators and devices were a bottleneck. Being able to run Android tests 
on x86 at "desktop speed" means we can greatly improve our test coverage 
on Android!

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

Re: Intent to Ship: Shadow DOM and Custom Elements

[Chris Peterson]

On 2018-08-15 9:04 AM, smaug wrote:


Why does https://caniuse.com/#feat=shadowdomv1 show Firefox 63 show 
not supported by default?






No idea. I don't know who maintains caniuse and when the they update it. 
Please report to them that they may want to update the page.



The caniuse data is manually maintained on GitHub:

https://github.com/Fyrd/caniuse

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

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

[Chris Peterson]

Awesome! This should fix some common webcompat issues for 
Firefox/GeckoView on Android.


What are the criteria for letting -webkit-appearance ride the trains? 
The GeckoView team is eager to ship mobile webcompat fixes, so they 
might be willing to accept more risk than Firefox desktop.


Are there any significant differences between -webkit-appearance on 
Chrome and WebKit? Chrome has more mobile market share than Safari, but 
many of these mobile sites may have been written when a -webkit- prefix 
actually meant WebKit. :)



On 2018-08-07 3:16 PM, Jonathan Watt wrote:

Summary
---

I plan to enable the pref in Nightly builds (using EARLY_BETA_OR_EARLIER) to
turn on the '-webkit-appearance' alias for '-moz-appearance'. This pref
simultaneously changes the behavior of the 'menulist-button' value, and shortly
the 'button-bevel' value.

Spec: None. We're reverse engineering Chrome and ignoring
   https://drafts.csswg.org/css-ui-4/#appearance-switching
   since the 'appearance' property defined there is not
   web compatible.

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

Preferences: layout.css.webkit-appearance.enabled

Platfrom coverage: All

Estimated release: 63 (tentatively)

Known webcompat impact: 19 out of 20 of the open -webkit-appearance
webcompat.org issues are fixed by this change.


The alias
-

The primary concern currently is to get `-webkit-appearance: none` shipped to
fix a bunch of web compat issues and unblock geckoview. That said, previously we
tried to implement and ship the 'appearance' property with only the values
'none' and 'auto' (as per CSS UI 4), along with a '-webkit-appearance' alias.
That attempt was unsuccessful for various reasons, but mainly because cascading
of a '-moz-appearance' other than 'none'/'auto' would not replace a lower
specificity 'appearance' value, breaking current web content and user
expectations about how the properties should cascade.

This time around by aliasing '-webkit-appearance' to '-moz-appearance' our
implementation of '-webkit-appearance' will support all the values that
'-moz-appearance' supports, avoiding the funky cascading issues.


Changes in behavior for existing values
---

Aliasing means that we'll recognize and react to a bunch of other
'-webkit-appearance' values that sites set, so to minimize the chances of
undesirable changes on existing web content, we've also been changing the
behavior of some '-moz-appearance' values to more closely align with the way
that Chrome handles the values of the same name for '-webkit-appearance'. Some
of those changes have shipped. The two that haven't are guarded behind the same
pref that turns on the '-webkit-appearance' alias: 'menulist-button' and
'button-bevel'. (They probably don't need to be though, so we could potentially
ship those separately if desirable.)

Both 'menulist-button' and 'button-bevel' occur two orders of magnitude fewer
than 'none' as a '-moz-appearance' value in github repos, and almost all the
occurrences for the two values seem to be non-interesting.

menulist-button
   https://github.com/search?o=desc=-moz-appearance+menulist-button=Code

   I dug through hundreds of these and didn't encounter any instances
   that would impact web content. The vast majority appear to occur in
   forks of the Mozilla source or appear in a list of possible values in
   csslint.js.

   The change here makes us display the appearance of an entire (collapsed)
   menulist, not just the drop marker to its right. That makes the change
   here more substantial and so in principal breakage could be significant.

button-bevel
   https://github.com/search?o=desc=-moz-appearance+button-bevel=Code

   Again, I dug through hundreds of these with the same observation as
   for menulist-button. Even in the places where it is used, border is
   typically overridden meaning that there will likely be no visual
   change for consumers.

   Additionally, the difference between the way button-bevel currently
   displays and how it will be changed to match Chrome is minimal.

Perhaps more significant is the usage count of the various values reported by
the crawl MS did for Edge:

https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/-webkit-appearance/

Blink/Webkit have no equivalent to our old behavior for 'menulist-button' (show
a dropmarker) which indicates that demand hasn't been high enough for them to
add that functionality. Given that, I expect the number of sites using and
depending on our old 'menulist-button' behavior are extremely low.

Blink's 'square-button' (which behaves the same as our 'button-bevel') was only
used on 0.002% of the pages that they crawled, and again, the visual appearance
change we're making is minimal.


Further aligning '-moz-appearance' with '-webkit-appearance'


I've filed a bunch of bugs for the differences that I'm aware of 

Re: Using clang-cl to ship Windows builds

[Chris Peterson]

How does the performance of clang-cl builds compare to MSVC builds on 
benchmarks like Speedometer?



On 2018-07-10 1:29 PM, David Major wrote:

Bug 1443590 is switching our official Windows builds to use clang-cl
as the compiler.

Please keep an eye out for regressions and file a blocking bug for
anything that might be fallout from this change. I'm especially
interested in hearing about the quality of the debugging experience.

It's possible that the patch may bounce and we'll go back and forth to
MSVC for a while. You can check your build's compiler at
`about:buildconfig`. Treeherder is running an additional set of MSVC
jobs on mozilla-central to make sure we can fall back to a green MSVC
if needed.

Watch for more toolchain changes to come. The next steps after this
will be to switch to lld-link and enable ThinLTO. That will open the
door to a cross-language LTO that could inline calls between Rust and
C++. In the longer term we can look into cross-compiling from Linux.

But for now, shipping our most-used platform with an open-source
compiler is a huge milestone in and of itself. Big thanks to everyone
who has contributed to this effort on the Mozilla side, and also big
thanks to the developers of LLVM and Chromium who helped make clang on
Windows a realistic possibility.
___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev


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

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

[Chris Peterson]

On 2018-05-23 1:35 PM, Botond Ballo wrote:

There is also work being done in this area outside the formal
standards process, in the form of the C++ Core Guidelines [2] (some of
which can be checked statically) and the accompanying Guideline
Support Library [3], and in the form of Microsoft's lifetime checker
[4], though that seems to be progressing very slowly, and even though
I ask for an update at every meeting, I haven't seen much of substance
there.


Facebook's Infer static analysis tool is adding more deeper checks for 
ownership lifetimes. They describe it as a "rough prototype of 
Rust-style borrow checker for C++."


https://github.com/facebook/infer/releases/tag/v0.14.0
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: C++ virtual function declarations should specify only one of virtual, final, or override

[Chris Peterson]

On 2018-02-16 12:54 PM, Ben Kelly wrote:

Are we supposed to just use override or final on methods that are overriden
when the class itself is marked final?

Personally writing final again seems redundant with the class level final
and the override keyword seems more informative.


You could use either final or override. My lint just checks syntax 
(using a regular expression). It doesn't know whether the class is final 
or whether a function declaration without any virtual/final/override 
specifier is overriding a base class's virtual function. (A clang plugin 
could.)


Specifying final might be safer than override. Someone might later make 
the class not final and then the `override` functions in the class can 
now be overridden. "final" is also shorter than "override". :)


final implies override *if* the function declaration does not also 
specify virtual. You can't tell whether `virtual void Huh() final` is 
overriding a base class function Huh() or actually declaring a new 
"virtual" function that can never be overridden. I found a few instances 
of these virtual/final declarations in mozilla-central. That's why the 
style guide recommends never using more than one of virtual, final, or 
override.


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

Re: PSA: C++ virtual function declarations should specify only one of virtual, final, or override

[Chris Peterson]

On 2018-02-16 1:07 PM, L. David Baron wrote:

   virtual void Bad1() final

I think there might be some legitimate use cases for this one, when
a function needs to be virtual because it's required for the calling
convention (as part of a binary plugin API or binary embedding API,
for example), but it's also not to be overridden, and it's also not
overriding a virtual function on a base class.  While we've moved
away from binary plugin interfaces, I could imagine it the
definition of an API for embedding Gecko or some part of it.


That's an interesting point and there are some possible workarounds (below).

btw, I found four such non-overriding virtual/final declarations in 
mozilla-central (links below) while writing this lint script:


1. NOT_INHERITED_CANT_OVERRIDE is a debug macro that declares a 
non-overriding final virtual function (BaseCycleCollectable) as a 
compile-time check of some properties of CC-able classes.


2. AccessibleNode::GetParentObject(). GetParentObject() is a common 
virtual function in many DOM classes, but AccessibleNode does not derive 
from any base classes the define GetParentObject(). I think this might 
be some code that was copy/pasted. It doesn't need to be virtual.


3. WebCryptoTask::CalculateResult() and CallCallback() mirror virtual 
function names in the CryptoTask class, though WebCryptoTask does not 
actually derive from CryptoTask. These classes used to share code but 
were decoupled (in bug 1001691) so WebCryptoTask could be used on worker 
threads. These functions don't need to be virtual.


4. nsWindowBase::GetWindowHandle(), which does not override any base 
class functions. The only other function named GetWindowHandle() is 
MouseScrollHandler::EventInfo::GetWindowHandle() in an unrelated class.




I think it's reasonable to warn for it since the above case should
be pretty rare, but I'd be a little concerned about forbidding it
completely.


My lint check is currently written to run on checkins, so its warning 
would be treated as an error on Treeherder. Possible workarounds:


* Individual files or directories to be whitelisted in the lint script. 
This is easy.


* The virtual and final keywords could be moved to different lines. My 
lint is just a complicated regular expression and can't analyze virtual 
function declarations that span multiple lines.



[1] 
https://searchfox.org/mozilla-central/rev/a5abf843f8fac8530aa5de6fb40e16547bb4a47a/xpcom/base/nsCycleCollectionParticipant.h#619-629


[2] 
https://searchfox.org/mozilla-central/rev/a5abf843f8fac8530aa5de6fb40e16547bb4a47a/accessible/aom/AccessibleNode.h#37


[3] 
https://searchfox.org/mozilla-central/rev/a5abf843f8fac8530aa5de6fb40e16547bb4a47a/dom/crypto/WebCryptoTask.h#182,184


[4] 
https://searchfox.org/mozilla-central/rev/cac28623a15ace458a8f4526e107a71db1519daf/widget/windows/WinMouseScrollHandler.h#191

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

PSA: C++ virtual function declarations should specify only one of virtual, final, or override

[Chris Peterson]

Mozilla's C++ style guide [1] says (since 2015) virtual function 
declarations should specify only one of `virtual`, `final`, or `override`.


Over the weekend, I will land a mach lint check (bug 1436263) that will 
warn about some virtual style violations such as:


  virtual void Bad1() final
  void Bad2() final override
  void Bad3() override final

It won't warn about the redundant `override` in `virtual void NotBad() 
override` at this time because there are 8000+ instances in 
mozilla-central. Also, virtual/override is more of a style issue whereas 
virtual/final can mask real bugs.


A clang-tidy check would be more thorough, but this mach lint is better 
than nothing until someone steps up to write a proper clang plugin. :) 
We had a clang-tidy check but it was disabled recently (bug 1420366) 
because it was too noisy (because it analyzed the post-processed source 
after NS_IMETHOD macros had been expanded to `virtual`).



[1] 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style

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

Chrome will start marking HTTP pages as "Not secure"

[Chris Peterson]

Chrome will start marking HTTP pages as "Not secure" in July 2018 
(Chrome 68):


https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html

Firefox has a similar insecure HTTP warning icon, currently disabled by 
the `security.insecure_connection_icon.enabled` pref added in bug 1310447.


Are there any blockers for Firefox shipping this feature?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Avoid invoking Debug formatters in release-mode Rust

[Chris Peterson]

On 2018-01-12 9:07 PM, Bobby Holley wrote:

The most
common way this seems to happen is in panic!() messages, where it can be
tempting to include a stringified value to make the message more
informative.


Just a friendly reminder: panic messages that are parameterized to 
include debug data might expose PII in Firefox crash reports. Patches 
that add new parameterized panic messages should probably be reviewed by 
a data steward:


https://wiki.mozilla.org/Firefox/Data_Collection
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Start Time and Daylight Savings

[Chris Peterson]

On 2017-11-06 9:46 AM, Justin Wood wrote:

Now with Taskcluster the start time is anchored in UTC so doesn't move
along with Daylight Savings, currently anchoring at 10am and 10pm UTC.


How long do the Nightly builds typically take? If the builds are started 
at 10am and 10pm UTC (2am and 5pm PST), when will the updates be live?

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

Re: We need better canaries for JS code

[Chris Peterson]

On 2017-10-18 4:51 AM, Mark Banner wrote:

I expect that this will find a number of lurking errorsy, so we may want
to migrate code progressively, using a directive, say "use strict
moz-platform" and static analysis to help encourage using this directive.
It would definitely be interesting to fail tests on some of the strict 
failures. I was surprised when I recently turned on the pref again to 
see how many warnings there were.


Having looked through a few of those, I've just found at least one issue 
, though 
non-critical, and I'm thinking we want to get the no-unused-expressions 
 rule turned on 
for ESLint as a result.


Bug 1394556 just enabled strict mode by default for all JSM components 
in Firefox 57.


Bug 807862 suggested enabling strict mode by default for all builtin 
Firefox JS, but it was resolved incomplete because of concerns about 
add-on compatibility. Nosy add-ons could reach up the stack into Firefox 
JS with code like `arguments.callee.caller.caller.caller.name == 
"sss_duplicateTab"`. Perhaps that is worth revisiting now that we only 
support WebExtensions in 57+.

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

Re: Changes to tab min-width

[Chris Peterson]

On 2017-10-03 2:18 PM, Boris Zbarsky wrote:
Right now, at 60px, I can see 7-10 chars in a tab title.  This is 
sometimes (but not always) enough for me to make sense of what I'm 
looking at when the favicon is not helpful.  For example, for bugzilla 
bugs I can see the whole bug number.


In the new setup is sounds like I will see 1-2 chars.  At that point, 
it's not immediately clear to me that there's any value to not just 
setting the min-width to "40px" and allowing all the title text to 
disappear altogether.  There is definite value in not going below the 
"keep the favicon entirely visible" value, of course.


I think tab bar usability would be much improved if the tab bar's 
drop-down list of full tab titles was always available. This is the "V" 
button that appears to the right of the "+" tab button.


On my machine, the drop-down list button only appears after 15 tabs are 
open, but (as Boris points out) the tabs stopped being identifiable 
before 15 tabs were open.

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

Re: test-verify now running as tier 2

[Chris Peterson]

This is very cool, Geoff! People have been talking about this idea for a 
long, so it is great to see it actually running. I'm glad to see chaos 
mode being tested, too.



On 2017-10-02 10:11 AM, Geoffrey Brown wrote:

Today the test-verify test task will start running as a tier 2 job.
Look for the "TV" symbol on treeherder, on linux-64 test platforms.

TV is intended as an "early warning system" for identifying the
introduction of intermittent test failures. When a mochitest, reftest,
or xpcshell test file is modified on a push, TV runs that particular
test over and over until it fails (orange job, standard failure
messages), or until max iterations are achieved (green job, all's
well), or until TV runs out of time (green job, maybe all's well?). As
a consequence, when a new test is added or a test is modified and an
intermittent failure is introduced, TV will usually be the first job
to fail, and it will fail on the push that modified the test, making
it (usually) simple to identify where the intermittent was introduced.

In future I hope to run TV on more platforms, apply it to more test
suites, and refine the --verify implementation to find intermittent
failures more efficiently. As a tier 2 task, TV failures will be
starred but will not cause backouts. I hope to move to tier 1 once TV
is proven to be effective.

More info at [1]. Bug and enhancement requests welcomed: please file
bugs blocking bug 1357513.

[1] https://developer.mozilla.org/en-US/docs/Test_Verification



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

Re: Coding style: Placement of binary operators when breaking a long line

[Chris Peterson]

On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:
The interesting points to consider is the data that Nick alluded to in 
the previous discussion about the existing prevalent style.


Also, the point you up about the pragmatic aspect of the need to be able 
to use automated tools in order to manage our Coding Style is right on. 
As things stand, the only viable option of such a tool that I'm aware of 
is clang-format, and given the standing situation with regards to what 
formatting options we can make that tool support in this case, I think 
the pragmatic decision is to pick *one* option here for the placement of 
operators across line breaks: either at the end of long lines or in the 
beginning of the next line.


The combination of the above points makes me prefer adopting the 
proposal to treat all operators like && and ||.


There are only a couple hundred instances of boolean operators after a 
line break in mozilla-central C++ code. I know this search is inexact, 
but it shows the (small) scale of this usage compared to the proposed 
before-line-break style.


https://searchfox.org/mozilla-central/search?q=%5E%5Cs%2B(%3E%7C%3E%3D%7C%3C%7C%3C%3D%7C%3D%3D%7C!%3D)%5Cs%2B(%5Cw%7C%5C()=true=true=.c
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

[Chris Peterson]

On 2017-09-06 11:48 AM, Tom Ritter wrote:

Steam's hardware survey shows the following distribution percentages.

Less than 512 MB 0.00%
512 Mb to 999 MB 0.03%
1 GB 0.52%
2 GB 3.30%
3 GB  6.27%
4 GB  14.96%
5 GB  0.66%
6 GB  3.23%
7 GB  2.33%
8 GB  42.77%
9 GB  0.04%
10 GB  0.29%
11 GB  0.18%
12 GB and higher  25.39%


The memory distribution of Firefox desktop users is shared on the 
Firefox Hardware Report dashboard. Unsurprisingly, Firefox users have 
less memory than Steam users.


https://hardware.metrics.mozilla.com/#goto-cpu-and-memory
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylo now the default configuration for mozilla-central

[Chris Peterson]

On 2017-09-05 1:10 PM, J. Ryan Stinnett wrote:

Assuming bug 1330412 sticks, Stylo will be the default configuration for
mozilla-central for all platforms except Android.  Thanks to everyone
involved with Stylo that helped us reach this stage!


Awesome! Thanks for flipping the switch, Ryan.



To ensure the old style system remains functional as a fallback,
separate "Stylo
disabled" test platforms have been added. We will also have a small subset
of the population using the old style system via experiments.


Just to be clear, the "stylo-disabled" test platforms will ride the 
trains to Beta and Release to ensure that Gecko's old style system has 
complete test coverage, in case we need to disable Stylo and revert to 
the old style system at the last minute of Beta 57.


We can stop testing the "stylo-disabled" test platforms on Mac and 
Windows after we ship Stylo to Release. We can remove them entirely 
after we ship Stylo on Android.

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

Re: Stylesheet wait timeout?

[Chris Peterson]

Maybe this is stylesheet delay is related to Context Driven Priority 
(CDP) project that changes how network requests are prioritized?


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


On 2017-08-31 10:46 AM, Dustin Mitchell wrote:

I've been seeing this, too, often on github pages.  I do not have
stylo enabled per about:support ("false (disabled by default)").

Dustin

2017-08-31 13:45 GMT-04:00 Chris Peterson <cpeter...@mozilla.com>:

Gerv, do you have Stylo enabled? Even if you did not flip the pref
(layout.css.servo.enabled), you might be in the Stylo experiment for Nightly
users. Check about:support for "Stylo".




On 2017-08-31 10:24 AM, Gervase Markham wrote:


On 18/08/17 12:11, Gervase Markham wrote:


Whereas what I meant to say was:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page? In the past few weeks I've
seen many more instances of a page loading unstyled, then re-laying out
a second later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.

I think we may have set the timeout a bit low, because the result is ugly.

I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.

Gerv



___
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: Stylesheet wait timeout?

[Chris Peterson]

Gerv, do you have Stylo enabled? Even if you did not flip the pref 
(layout.css.servo.enabled), you might be in the Stylo experiment for 
Nightly users. Check about:support for "Stylo".




On 2017-08-31 10:24 AM, Gervase Markham wrote:

On 18/08/17 12:11, Gervase Markham wrote:


Whereas what I meant to say was:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page? In the past few weeks I've
seen many more instances of a page loading unstyled, then re-laying out
a second later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.

I think we may have set the timeout a bit low, because the result is ugly.

I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.

Gerv



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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Chris Peterson]

On 2017-08-21 5:31 PM, Eric Rahm wrote:

I'm not sure how much backing that has -- we'd be going from nsString =>
String which is pretty close to std::string -- it would be interesting to
get some feedback.


Or follow Rust's precedent and use type name `Str`. That would avoid 
confusion with std::string or #include "string.h" on case-insensitive 
file systems.

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

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

I see what you mean. The chart is abstract, but I see how the relative 
sizes do imply more than intended. I like your suggestion to use up and 
down arrows.


chris


On 2017-08-14 7:42 PM, Ben Kelly wrote:

Chris,

Do you know who controls this blog post?

https://blog.mozilla.org/firefox/firefox-64-default-64-bit-windows/

The chart is really misleading.  What does the vertical bar chart for
"security" even mean?  As noted on twitter:

https://twitter.com/kylealden/status/897222041476005888

The bar chart for "crashes" at least has an intelligible y-axis, but it
seems wrong.  The chart shows more like a 60% improvement instead of a 39%
improvement.

Perhaps we should just replace this graphic with an up-arrow for security
and a down-arrow for crashes?

Anyway, sorry to be pedantic, but misleading charts are kind of a pet peeve.

Thanks.

Ben

On Wed, Jul 19, 2017 at 2:38 AM, Chris Peterson <cpeter...@mozilla.com>
wrote:


We are on track to make 64-bit Firefox the default build for Win64 OS,
bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox
users running Win64.

PLANS:

* In Firefox 55 (August 8), the Windows stub installer will default to
64-bit Firefox for eligible users (Win64 and 2+ GB RAM).

* In Firefox 56 (September 26), we will migrate existing eligible 32-bit
Firefox users to 64-bit. About 70% of Windows Firefox users currently run
32-bit Firefox build on Win64. Nearly all of these users can be migrated to
64-bit Firefox.

Our Win64 project wiki has more details about the long road to making
64-bit Firefox the default:

https://wiki.mozilla.org/Firefox/Win64

PROGRESS:

* David Parks fixed the insidious Flash video streaming bug affecting
Xfinity and MLB! (bug 1334803)

* Bob Owen fixed the sandbox issue that prevented 64-bit Firefox from
being run from a network-mounted drive! (bug 1377555)

* Some highlights from week 2 of our Firefox 54 experiment comparing 32-
and 64-bit Firefox users:

- About 8% of Windows users have <= 2 GB RAM!

- User retention and engagement metrics (session length, # of pages, # of
tabs) are about the same for 32- and 64-bit Firefox users, regardless of
memory size.

- 64-bit content process crash rate is about the same as 32-bit for users
with 2 GB and about 20% less with 2+ GB!

- 64-bit browser process crash rate is about the same as 32-bit for users
with 2 GB and about 20% less with 2+ GB!

- 64-bit plugin process crash rate is about 50% less than 32-bit for users
with 2 GB and 80% less with 2+ GB!

We are still considering whether 64-bit Firefox should have a default
minimum memory requirement. As a placeholder value, Firefox 55 currently
requires 2+ GB, but based on the results of our experiment, we may remove
the minimum memory requirement. Microsoft's minimum memory require for
Win64 itself is 2 GB, so anyone running Win64 with less than 2 GB is having
a bad time.
___
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 to make your local --enable-optimize builds compile Rust faster

[Chris Peterson]

Matt Brubeck just a patch to disable Rust LTO on local Firefox builds, 
so you no longer need to manually apply Nathan's patch to disable LTO 
locally.


https://bugzilla.mozilla.org/show_bug.cgi?id=1386371#c34


On 2017-08-09 11:49 AM, Nathan Froyd wrote:

TL; DR: apply 
https://github.com/froydnj/gecko-dev/commit/12a80904837c60e2fc3c68295b79c42eb9be6650.patch
to get faster --enable-optimize local builds if you are working on
Stylo or touching Rust in any way.  Please try to not commit it along
with your regular patches. =D

You may have noticed that Rust compile times for --enable-optimize
builds have gotten worse lately.  This is partly due to the large
amount of Rust code we now have (with more on the way, surely), but
also because our Rust code builds with Rust's link-time optimization
(LTO) for such builds.  Building our Rust code this way makes our
binaries smaller, but imposes significant compile-time costs.

Bug 1386371 is open to track disabling LTO in Rust code on
non-automation builds, but in the absence of a solution there, I have
written a patch:

https://github.com/froydnj/gecko-dev/commit/12a80904837c60e2fc3c68295b79c42eb9be6650.patch

which you can apply in your local repository.  Having local patches is
obviously not optimal, as there's a risk that they will be committed
accidentally, but it's probably the best solution we have right now.

I know you have suggestions and/or questions, so let's transition to a
Q format:

Q: This patch is great, my compile is as fast as a photon!  Why don't
we just commit the patch?

A: Compiling without LTO imposes significant binary size costs.  We
don't have a great way to leave LTO disabled for local builds, but
enable it for automation builds.

Q: We can pass in flags to rustc via `RUSTFLAGS`: we can set
RUSTFLAGS="-C lto" for automation builds!  Why not do that?

A: Because rustc complains about compiling all of our intermediate
rlibs with `-C lto`.

Q: Ugh.  Could we fix rustc to not complain?

A: rustc's behavior here, while reasonable, is certainly fixable.
This or the Cargo modifications, below, are feasible options for
fixing things.

Q: Why modify Cargo?  We could run our Cargo.toml files through a
preprocessor before passing them to `cargo`, setting `lto`
appropriately for the style of build we're doing.  Wouldn't that work?

A: The output of the preprocessed Cargo.toml would then live in the
objdir, which wouldn't play well with Cargo.lock files.  Upgrading
Rust packages would require a complicated dance as well, which in turn
would affect things like the servo syncing service on autoland.

Q: What if we put the generated Cargo.toml in the srcdir instead?

A: This idea is sort of feasible, but then the build process is
modifying the srcdir, which is far from ideal: we have actively fixed
instances of this happening in the past.  Upgrading packages would
also be a pain, for similar reasons as the previous question.

Q: Huh.  OK, so what are we doing?

A: The current idea, courtesy of glandium, is to add command-line
flags to Cargo to permit setting or overriding of arbitrary Cargo.toml
settings, and then add the appropriate flags to our Cargo invocations.
An initial implementation of this idea lives in
https://github.com/rust-lang/cargo/issues/4380, though there were
concerns expressed that this functionality might be a little
over-the-top for what we want to do, and making rustc stop complaining
(see above) might be a better fix.

Whichever fix we did--rustc or Cargo or maybe even both!--we'd need to
build in automation with newer versions of the appropriate tool, and
we'd need to ensure that local builds *didn't* use the options.  Both
of these solutions are reasonably simple, and it is entirely possible
that we could have the fix uplifted to beta Rust and therefore have
the fix available for the 1.20 release, which we're planning on using
to build 57.

Thanks,
-Nathan



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

Re: CodeCoverage! Monthly Update

[Chris Peterson]

Kyle, do you know if Rust code coverage is blocked on any remaining Rust 
toolchain issues?


chris


On 2017-08-10 11:31 AM, Kyle Lahnakoski wrote:



Did you have that sense you were missing something? Well, you were 
right: You were missing your ...


# *Monthly CodeCoverage! update!  \o/ *

/If you //want to hear more about an//y of the//s//e items, please 
contact me and I will get you more detailed information/*

*

*## **Summary of July*

  * *More hard work on the ETL pipeline*: Condensing the data to make
it manageable, and writing more efficient code for faster
processing. There is still more work to be done, but it's
working.  Marco summarized this work with an excellent blog post:
[1]
https://marco-c.github.io/2017/07/28/code-coverage-architecture.html
  * *Analyzing coverage variability* - If you recall from previous
months, I mentioned that different coverage runs show different
coverage numbers: We call this "coverage variability", and it even
exists when comparing two runs from the same revision. gmierz has
been looking into this variability to better understand its size,
and character. [2], [3]
  * *Finished detailed the plan for the MVP *[4] - This MVP is for
visualizing coverage of net-new lines: Relman is interested in the
coverage on the net-new lines of every changeset  This is hard
given we can only run coverage on every central push. We now have
a plan for how to get this done, as best as possible, with the
information given.

*## Plans for August*

  * *Build the MVP* - Visualize coverage of net new lines by
changeset: Now that we have a plan,  armenzg has already started
the frontend UI work [5], [6], and will be working with marco
working on the backend [7]
  * *Continue work on optimizing the ETL pipelines* - necessary work *
*

*
**## Meetings*

We have weekly CodeCoverage meetings, and you are welcome to attend:

  * When: Held every Friday @ 11:30 EDT (08:30 PDT)
  * Where: Kyle's video room
https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
  * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17


*## Reference*

[1] Blog post on coverage collection and aggregation: 
https://marco-c.github.io/2017/07/28/code-coverage-architecture.html


[2] Variability analysis code - 
https://github.com/gmierz/coco-variability-tools


[3] Example variability output - 
https://gmierz.github.io/variability/variability_index.html


[4] Details for UI - 
https://public.etherpad-mozilla.org/p/code_coverage_Q3_17


[5] Code for UI - https://github.com/armenzg/code_cov_experiments

[6] Example UI (very rough, but stay tuned!) - 
https://armenzg.github.io/code_cov_experiments/


[7] Code for backend - 
https://github.com/mozilla-releng/services/tree/master/src/shipit_code_coverage





On 2017-07-06 21:37, Kyle Lahnakoski wrote:




## Summary of Past Quarter

Coverage is enabled for nearly all tests, and scheduled every push [1]!!

  * All c/c++ test suites have coverage enabled
  * talos coverage is enabled
  * jsvm[7] coverage is enabled, and running
  * codecov.io [2] shows the results, broken down by directory

## Plans for Q3

The overall plan for Q3 is laid out in the planning document [12].  
Put simply, a **coverage differential viewer**, operating at low 
resolution (per central push), has enough promise to justify Q3 
effort on CodeCoverage.


## The Complications

  * Rust code coverage is still delayed [6] - maybe by mid quarter
  * The data volume is very large; coveralls.io and codecov.io are
having some difficulty dealing with the volume.
  * There is instability in the coverage numbers due to variability
in our test runs; think GC and telemetry logic.  Multiple
coverage runs will be required to get a total coverage number
  * Intermittents are impacting coverage reliability - we will
require a coverage health monitor to know if coverage is "complete"

## Summary of this past June

  * upgrading tests to use Ubuntu 16.04
  * fixing blockers that stood in the way of rust coverage[6]
  * enabling coverage to even more suites, like talos [10]
  * adding JavaScript to the codecov/coveralls report
  * getting a handle on the volume of data code coverage is producing

## Plans for July

  * continued work on ETL pipeline
  * enable coverage for spidermonkey [11]
  * see the first hints of Rust coverage
  * build a coverage health monitor to deal with "the complications"
(above)

## Meetings

We have weekly CodeCoverage meetings, and you are welcome to attend:

  * When: Held every Friday @ 11:30 EDT (08:30 PDT)
  * Where: Kyle's video room
https://v.mozilla.com/flex.html?roomdirect.html=huhL8WaTwCwC
  * Etherpad: https://public.etherpad-mozilla.org/p/code_coverage_Q1_17


## Reference

[1] See coverage on TH 
https://treeherder.mozilla.org/#/jobs?repo=mozilla-central=ccov


[1b] Example on TH: 

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-08-07 1:19 AM, Nicholas Nethercote wrote:

I think the 2GB "requirement" from Microsoft should be ignored, because
plenty of our users are ignoring it.


By "ignore the 2GB requirement", are you suggesting we do or don't give 
64-bit Firefox to users with less than 2GB?


I am waffling again on having a minimum memory requirement at all. Our 
current minimum is actually 1800 MB, not 2048 MB. Only about 1% of Win64 
OS users actually have (0,1800) MB and only 5% have [1800,2048] MB. So 
we are talking about small differences in user retention and crash rates 
for only 1% of Win64 OS users.


As we are preparing to migrate Beta users to 64-bit, we see the minimum 
memory requirement adds new complexity to both the client and server 
components of the update process and extra QA for this one-time 
migration event.




On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson <cpeter...@mozilla.com>
wrote:


On 2017-08-06 11:26 PM, Henri Sivonen wrote:


On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson<cpeter...@mozilla.com>
wrote:


Users with only 2 GB and 5 minute browser sessions would probably have a
faster user experience with 32-bit Firefox than with 64-bit, but how do
we
weigh that experience versus the security benefits of ASLR?


Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
burden are we keeping by catering to users who've installed 64-bit
Windows with less than 2 GB of RAM in contradiction with what
Microsoft states as a requirement?



That's a fair question. 32-bit applications can only access 2 GB of
virtual address space on Win32 OS, but can access 4 GB on Win64 OS. So in
theory, some 32-bit pointer bugs could manifest differently on Win64 and
Win32.

Do we test 32-bit Firefox on Win32 or Win64 today? I know we build 32-bit
Firefox on Win64. Since more people will run 32-bit Firefox on Win32 than
on Win64, we should probably test on Win32 or at least test on Win64
configured to only allow Firefox access to 2 GB of virtual address space.

In our experiments with Win64 OS users, users with 2 GB or less had
slightly worse retention and crash rates when running 64-bit Firefox than
32-bit Firefox.

About 8% of Win64 users in our experiment had 2 GB or less, so we are
talking about choosing a worse user experience for a fair number of people.
(We didn't break out how many users had strictly less than 2 GB.) 64-bit
Chrome's minimum memory requirement is 4 GB, so Google has similarly
decided that supporting 32-bit on Win64 is worth the trouble.

___
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: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-08-06 11:26 PM, Henri Sivonen wrote:

On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson<cpeter...@mozilla.com>  wrote:

Users with only 2 GB and 5 minute browser sessions would probably have a
faster user experience with 32-bit Firefox than with 64-bit, but how do we
weigh that experience versus the security benefits of ASLR?

Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
burden are we keeping by catering to users who've installed 64-bit
Windows with less than 2 GB of RAM in contradiction with what
Microsoft states as a requirement?


That's a fair question. 32-bit applications can only access 2 GB of 
virtual address space on Win32 OS, but can access 4 GB on Win64 OS. So 
in theory, some 32-bit pointer bugs could manifest differently on Win64 
and Win32.


Do we test 32-bit Firefox on Win32 or Win64 today? I know we build 
32-bit Firefox on Win64. Since more people will run 32-bit Firefox on 
Win32 than on Win64, we should probably test on Win32 or at least test 
on Win64 configured to only allow Firefox access to 2 GB of virtual 
address space.


In our experiments with Win64 OS users, users with 2 GB or less had 
slightly worse retention and crash rates when running 64-bit Firefox 
than 32-bit Firefox.


About 8% of Win64 users in our experiment had 2 GB or less, so we are 
talking about choosing a worse user experience for a fair number of 
people. (We didn't break out how many users had strictly less than 2 
GB.) 64-bit Chrome's minimum memory requirement is 4 GB, so Google has 
similarly decided that supporting 32-bit on Win64 is worth the trouble.

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

Re: sccache as ccache

[Chris Peterson]

On 2017-08-05 10:49 AM, ISHIKAWA, Chiaki wrote:

However, I am not sure if the cache is working correctly.

With ccache, we can specify a log file in the environment variable 
CCACHE_LOGFILE to specify. We can study the log file to see if

the cache is indeed working (hits, etc).

Is there an equivalent of CCACHE_LOGFILE with sccache?
There was no trace of such logfile in the directory specified by 
SCCACHE_DIR.


You can check whether `sccache -s` stats show any sccache activity after 
building Firefox.


Adding `mk_add_options "export RUSTC_WRAPPER=sccache"` to my mozconfig 
has no effect according to my `sccache -s` stats, but adding `export 
RUSTC_WRAPPER=sccache` to my .bash_profile seems to work.


Is there a way to make cargo output more verbose during mach build? 
`mach build --verbose` doesn't seem to affect cargo.

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

Re: Heads up! Building Stylo in local developer builds

[Chris Peterson]

If you now see Mac compilation errors about "stdlib.h not found", try 
running `xcode-select --install`.


Part of the Stylo build process (rust-bindgen) can get confused about 
which clang header #include paths it should use. xcode-select can fix 
this. Bug 1366564 is a feature request for mach bootstrap to run 
xcode-select automatically.



On 2017-07-28 1:04 AM, Chris Peterson wrote:
Stylo support (pref'd off) has been built in automation builds for a 
couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo 
support (pref'd off) in local developer builds, too. You should rerun 
`mach bootstrap` to make sure you have the latest versions of the Stylo 
and Rust dependencies.


Stylo currently builds on Windows, Mac, and Linux64. Linux32 is 
temporarily blocked by some build issues. Android support will follow 
after Firefox 57. Stylo adds a lot of new Rust code, which slows down 
Firefox build times. The Firefox build peers and Rust developers are 
working on a couple different methods to improve Rust build times.


If you don't work directly on Rust code locally, the biggest speedup 
available is probably sccache, a drop-in replacement for ccache that 
also supports Rust. Ted shared instructions for installing sccache on 
dev-platform earlier this week [1]. IIUC, sccache works best on Linux. 
There are currently some sccache bugs on Mac [2] and Windows (bug 1318370).


To enable Stylo for testing, set the "layout.css.servo.enabled" pref = 
true and report problems in the #servo IRC channel.


[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5srcnP-Wj4E/Uf_2gw2NAAAJ 



[2] https://github.com/mozilla/sccache/issues/163


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

Re: Heads up! Building Stylo in local developer builds

[Chris Peterson]

btw, there is a mach bootstrap bug on Windows if you had previously 
installed the i686 rustc toolchain instead of the x86_64 toolchain:
Bug 1385241 - ./mach bootstrap: error: component 'rust-std' for target 
'i686-pc-windows-msvc' is required for toolchain 
'stable-i686-pc-windows-msvc' and cannot be re-added

You can fix this problem by running:
rustup default stable-x86_64-pc-windows-msvc

On 2017-07-28 1:04 AM, Chris Peterson wrote:
Stylo support (pref'd off) has been built in automation builds for a 
couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo 
support (pref'd off) in local developer builds, too. You should rerun 
`mach bootstrap` to make sure you have the latest versions of the Stylo 
and Rust dependencies.


Stylo currently builds on Windows, Mac, and Linux64. Linux32 is 
temporarily blocked by some build issues. Android support will follow 
after Firefox 57. Stylo adds a lot of new Rust code, which slows down 
Firefox build times. The Firefox build peers and Rust developers are 
working on a couple different methods to improve Rust build times.


If you don't work directly on Rust code locally, the biggest speedup 
available is probably sccache, a drop-in replacement for ccache that 
also supports Rust. Ted shared instructions for installing sccache on 
dev-platform earlier this week [1]. IIUC, sccache works best on Linux. 
There are currently some sccache bugs on Mac [2] and Windows (bug 1318370).


To enable Stylo for testing, set the "layout.css.servo.enabled" pref = 
true and report problems in the #servo IRC channel.


[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5srcnP-Wj4E/Uf_2gw2NAAAJ 



[2] https://github.com/mozilla/sccache/issues/163


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

Heads up! Building Stylo in local developer builds

[Chris Peterson]

Stylo support (pref'd off) has been built in automation builds for a 
couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo 
support (pref'd off) in local developer builds, too. You should rerun 
`mach bootstrap` to make sure you have the latest versions of the Stylo 
and Rust dependencies.


Stylo currently builds on Windows, Mac, and Linux64. Linux32 is 
temporarily blocked by some build issues. Android support will follow 
after Firefox 57. Stylo adds a lot of new Rust code, which slows down 
Firefox build times. The Firefox build peers and Rust developers are 
working on a couple different methods to improve Rust build times.


If you don't work directly on Rust code locally, the biggest speedup 
available is probably sccache, a drop-in replacement for ccache that 
also supports Rust. Ted shared instructions for installing sccache on 
dev-platform earlier this week [1]. IIUC, sccache works best on Linux. 
There are currently some sccache bugs on Mac [2] and Windows (bug 1318370).


To enable Stylo for testing, set the "layout.css.servo.enabled" pref = 
true and report problems in the #servo IRC channel.


[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5srcnP-Wj4E/Uf_2gw2NAAAJ


[2] https://github.com/mozilla/sccache/issues/163
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Keyboard APZ has landed on Inbound

[Chris Peterson]

On 2017-07-21 11:05 PM, Ryan Hunt wrote:

The patch to enable async keyboard scrolling in nightly (for all platforms
except Android) has landed on inbound.

Once this is merged to central, key scrolling will be done by the compositor
instead of on the main thread in most cases. This should bring the
responsiveness of key scrolling in line with other input methods like mouse
wheel, scroll bar, and touch dragging which have already converted to APZ.


Awesome!


There may be issues with this enabled. Please test this out, and if you find
any regressions please file bugs blocking bug 1352654.


Should that be APZ bug 1376525? Bug bug 1352654 looks like a WebRender 
bug for gradient display items.

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

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-07-19 6:58 PM, Mike Hommey wrote:

I don't understand why that would be, but if so it should show in
crashstats as fewer small OOMs on these devices.  Does the data actually
show that?


I don't know. Can that be filtered?


I'm not sure I'm answering the right question, but searching through 
crash reports from Firefox 53/54 users over the last 30 days, I see 
small OOMs from both 32- and 64-bit users, regardless of available 
physical or virtual memory or browser uptime. But small OOMs are always 
the top crash (10% or more) for 32-bit users. Small OOMs are about 6% 
for 64-bit users with <= 2 GB, 3% with <= 4 GB, and 1% for > 4 GB.


Here is a search for 32-bit crash reports with <= 2 GB physical memory:
https://is.gd/205aNb

And 64-bit crash reports with <= 2 GB physical memory:
https://is.gd/AezNaZ

But I see a lot of strange crash reports, such as small OOMs from 64-bit 
users within 10 seconds of starting Firefox. Or small OOMs from 64-bit 
users with 9 GB of available physical memory and 128 TB of available 
virtual memory.




I'm not saying they shut down because of memory. I'm saying a surprising
lot of people have browser sessions that don't last more than 5 minutes
(I've heard multiple times in the past years that we found that out from
our data).
Those people are not going to see OOM.


Users with only 2 GB and 5 minute browser sessions would probably have a 
faster user experience with 32-bit Firefox than with 64-bit, but how do 
we weigh that experience versus the security benefits of ASLR?

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

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-07-19 10:18 AM, Mike Hoye wrote:

On 2017-07-19 3:58 AM, Chris Peterson wrote:

On 2017-07-19 12:01 AM, Mike Hommey wrote:

What's the plan for eligible people that still want to keep 32-bit
Firefox? 
Outside of our QA team (or others orgs, I guess?) do we have a set of 
use cases that would motivate people to flip that switch?


64-bit code is slightly larger, so there is some memory overheard. Users 
with less than 4 GB RAM might feel that 32-bit is faster on their 
machine, but our testing on Windows 7 and 10 machines with just 2 GB RAM 
doesn't show any measurable performance differences. We don't expect 
64-bit Firefox to have any performance improvements over 32-bit. The 
benefits of 64-bit are primarily ASLR and fewer OOM crashes, which are 
somewhat intangible to end users.




Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory 
requirement.


We have two options in mind: 
Is ESR on the radar while you're planning this, or is it unrelated? 


When the next ESR comes around (59?), we will announce to the ESR 
mailing list that 64-bit is considered stable and the preferred version, 
but we do not plan to auto migrate 32-bit ESR users to 64-bit. We figure 
that enterprises will want to test and control their deployments.

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

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-07-19 12:01 AM, Mike Hommey wrote:

What's the plan for eligible people that still want to keep 32-bit
Firefox? Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory requirement.


We have two options in mind:

1. An opt-out registry key (piggybacking on an updater feature mhowell 
or rstrong is developing). We would document this registry key before 
the 56 release so 32-bit users would have time to set it and prevent 
migration.


2. 56 will be a watershed release (for multiple reasons), so all users 
updating from old versions will get 56.0 before then updating to any 
future updates. We will limit the migration to exactly one version 
(probably a 56.0.1) so 32-bit users who were migrated but don't want 
64-bit can manually re-install 32-bit 56.0.1 and not be re-migrated in a 
later update.




Other than end users, I can imagine it being a problem for developers or
QA at some point.

Also, what about beta, developer edition and nightly?


Our current plan is to not migrate 32-bit Nightly users to 64-bit. We 
haven't made a decision about Beta or Developer Edition users. About 60% 
of Beta users don't actually know they are on the Beta channel, so they 
are not typical pre-release testers and would benefit from 64-bit. With 
the opt-out registry key and the 56.0.1 watershed migration, there are 
options for developers and testers who don't want to be migrated. Given 
the options, is there any strong reason to not migrate Beta and/or 
Developer Edition users?

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

64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

We are on track to make 64-bit Firefox the default build for Win64 OS, 
bringing improved ASLR and fewer OOM crashes to the 70% of Windows 
Firefox users running Win64.


PLANS:

* In Firefox 55 (August 8), the Windows stub installer will default to 
64-bit Firefox for eligible users (Win64 and 2+ GB RAM).


* In Firefox 56 (September 26), we will migrate existing eligible 32-bit 
Firefox users to 64-bit. About 70% of Windows Firefox users currently 
run 32-bit Firefox build on Win64. Nearly all of these users can be 
migrated to 64-bit Firefox.


Our Win64 project wiki has more details about the long road to making 
64-bit Firefox the default:


https://wiki.mozilla.org/Firefox/Win64

PROGRESS:

* David Parks fixed the insidious Flash video streaming bug affecting 
Xfinity and MLB! (bug 1334803)


* Bob Owen fixed the sandbox issue that prevented 64-bit Firefox from 
being run from a network-mounted drive! (bug 1377555)


* Some highlights from week 2 of our Firefox 54 experiment comparing 32- 
and 64-bit Firefox users:


- About 8% of Windows users have <= 2 GB RAM!

- User retention and engagement metrics (session length, # of pages, # 
of tabs) are about the same for 32- and 64-bit Firefox users, regardless 
of memory size.


- 64-bit content process crash rate is about the same as 32-bit for 
users with 2 GB and about 20% less with 2+ GB!


- 64-bit browser process crash rate is about the same as 32-bit for 
users with 2 GB and about 20% less with 2+ GB!


- 64-bit plugin process crash rate is about 50% less than 32-bit for 
users with 2 GB and 80% less with 2+ GB!


We are still considering whether 64-bit Firefox should have a default 
minimum memory requirement. As a placeholder value, Firefox 55 currently 
requires 2+ GB, but based on the results of our experiment, we may 
remove the minimum memory requirement. Microsoft's minimum memory 
require for Win64 itself is 2 GB, so anyone running Win64 with less than 
2 GB is having a bad time.

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

Re: More Rust code

[Chris Peterson]

On 7/10/17 4:48 PM, Xidorn Quan wrote:

The first thing comes to my mind is crash reports. It currently doesn't always 
include useful panic message from Rust, see for example [1] and [2]. Also for 
Stylo, we generate lots of code (including using bindgen and mako template 
system, bindgen is usually fine, but the code generated from template can 
contain lots of code logic), and when the crash happens inside generated code, 
it is pretty hard to understand what's going wrong, because there is no useful 
source link, see for example [3].
There are also issues from Rust side. I've always been using an optimized debug 
build locally (because that runs faster), and sometimes use Visual Studio to 
investigate issues. C++ code works fine with this configuration, but in Rust 
code, I cannot see any variable information. Stack backtrace seems to work fine 
to me, though.
[1]https://crash-stats.mozilla.com/report/index/2abff06f-d969-4ba5-845b-a98410170708[2]https://crash-stats.mozilla.com/report/index/03718a9c-9d98-4832-b8a6-026220170706[3]https://crash-stats.mozilla.com/report/index/6b7d1d78-8418-47ef-bee9-f49c20170710


Looking at those crash reports' signatures, we should probably add 
`core::option::expect_failed` and `core::str::slice_error_fail` to 
Socorro's list of function names to ignore [1]. Should Socorro ignore 
all Rust core::* or std::* function names when searching the backtrace 
for a useful signature?


[1] 
https://github.com/mozilla-services/socorro/tree/master/socorro/siglists#signatures-utilities-lists

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

Re: Linting for common causes of oranges in mochitests (need ideas)

[Chris Peterson]

On 7/6/17 11:47 AM, Andrew Halberstadt wrote:
# Are there additional things not listed on that page that we could lint 
for?


Do we want to discourage tests from using Date (`new Date` or 
`Date.now()`) for measuring time? Dates are affected by time zones, DST, 
and clock skew issues jumping forward or backward. The performance.now() 
API doesn't have any of those problems, plus it uses high-resolution 
timestamps with 5 microsecond resolution instead of 1 millisecond. In 
bug 1372261, mconley is changing the tps Talos test to use 
performance.timing.navigationStart + performance.now().

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

FYI: Questions about the Gecko Profiler? Drop by the #flow IRC channel.

[Chris Peterson]

Just a reminder: if you or engineers on your team have questions about 
using the Gecko Profiler (https://perf-html.io/), you can ask for help 
in the #flow IRC channel.

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

Re: Quantum Flow Engineering Newsletter #14

[Chris Peterson]

On 6/23/17 12:17 AM, Ehsan Akhgari wrote:


But to speak of a more direct measurement of performance, let's look 
at our progress on Speedometer V2 
.  
Today, I measured our progress so far on this benchmark by comparing 
Firefox 53, 54, 55.0b3 (latest beta as of this writing) and the latest 
Nightly, all x64 builds, on the reference hardware 
.  This is the result (numbers 
are the reported benchmark score, higher is better):


Speedometer improvements



How do these Speedometer V2 scores map to the results on AWFY? AWFY 
shows many Speedometer sub-tests, but no score in the range of 70.21. 
AWFY machine #36 is the reference hardware.


https://arewefastyet.com/#machine=36=breakdown=speedometer-misc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Profiling nightlies on Mac - what tools are used?

[Chris Peterson]

On 6/21/17 8:06 AM, Boris Zbarsky wrote:

On 6/21/17 10:44 AM, Ehsan Akhgari wrote:

It seems like that we have an answer now in the bug!
https://bugzilla.mozilla.org/show_bug.cgi?id=1338651#c129


Just for clarity, so people don't have to read the whole bug, changing 
the _path_ the build is at when it's compiled/linked results in the huge 
observed performance difference.  At least if I understand the comments 
in the bug correctly.


i.e. Mike Shal's patch here fixed multiple 30% Talos regressions!

-: WORKSPACE ${WORKSPACE:=/home/worker/workspace}
+: WORKSPACE ${WORKSPACE:=/builds/slave/try-m64-00}
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: HTML scoped style sheets (

[Chris Peterson]

On 6/20/17 2:14 AM, Cameron McCormack wrote:
Cameron, what bug should this one block (iiuc chrome support will be 
removed a bit later, so we have some time, do you already have a bug 
for that part?)


Actually, let me backtrack a little.  I might be misremembering our 
plans for Stylo in chrome documents.  Chris or Bobby, can you remind 
me whether we are still planning to target chrome documents?


If we are, then it makes it a little more urgent to remove current 
usages of 

Re: JSBC: JavaScript Start-up Bytecode Cache

[Chris Peterson]

Nicolas, when JSBC is enabled by default, should we change our test 
procedure for our various page load tests (Talos and Softvision's manual 
testing)? Since the first page load will be slower than subsequent page 
loads (as you noted in the bug [1]), should we throw away the first page 
load time or continue to average it with the subsequent page load times?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=900784#c72

chris


On 6/13/17 2:50 AM, Nicolas B. Pierron wrote:
The JavaScript Start-up Bytecode Cache⁰ is a project which aims at 
reducing the page load time by recording the bytecode generated during 
the last visits and by-pass the JavaScript parser.


This project changes the way we process JavaScript script tags which are 
fetched from the network, and cached. After multiple visits¹, the 
bytecode would be encoded incrementally², as soon as the bytecode 
emitter generates it. Once we reached some idle time³, we save the 
content encoded incrementally as an alternate data on the cache⁴.  The 
cache contains a compressed version of the source, the bytecode of 
functions which got executed during the start-up of the page, and all 
non-executed functions encoded as source indexes⁵.


On follow-up visits the script loader would load the alternate data 
instead⁶ of the source, and decode the bytecode either off-thread⁷ or on 
the current-thread.  This is expected to replace the syntax checker and 
the bytecode emitter for all recorded functions.


This feature is currently pref-ed off and can be enabled by setting the 
following preferences in about:config⁸:

   - dom.script_loader.bytecode_cache.enabled = true
   - dom.script_loader.bytecode_cache.strategy = 0

For any issue caused by this optimization, filed it as a blocker of Bug 
900784.


In the upcoming days, I will add telemetry probes to better tune the 
heuristics¹ for the web and monitor the known sources of fallback and 
failures. In addition, I will request for a pref-experiment, such that 
we can get more data from nightly users. At the moment, I expect to 
enable this feature around mid-July.


⁰ https://bugzilla.mozilla.org/show_bug.cgi?id=900784
¹ These are heuristics which would be customized by running a 
pref-experiment. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1362114)
² We cannot do it off-thread, nor after the execution (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1316081)
³ Currently set to the next cycle after the processing of the OnLoad 
event. (see https://bugzilla.mozilla.org/show_bug.cgi?id=1372207)
⁴ Thanks to Valentin Gosu for his work and support on the alternate data 
interface as part of necko. (see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1231565)

⁵ https://bugzilla.mozilla.org/show_bug.cgi?id=917996
⁶ This forces us to store the compressed source as part of the encoded 
bytecode, but prevent additional round-trip between the parent and child 
processes.

⁷ https://bugzilla.mozilla.org/show_bug.cgi?id=1316078
⁸ 
http://searchfox.org/mozilla-central/rev/d840ebd5858a61dbc1622487c1fab74ecf235e03/modules/libpref/init/all.js#212-233 


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

Re: Linux builds now default to -O2 instead of -Os

[Chris Peterson]

On 6/6/17 10:33 AM, Boris Zbarsky wrote:

On 6/1/17 9:04 PM, Mike Hommey wrote:

Ah, forgot to mention that. No, it doesn't affect *our* shipped builds
(because PGO uses a different set of optimization flags).

But it does affect downstream builds that don't PGO.


Based on the jump I see on June 2 at 
https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000=%5Bmozilla-central,80984697abf1f1ff2b058e2d9f0b351fd9d12ad9,1,1%5D=%5Bmozilla-central,ae68c64ef8bfa104fded89971f1c2c6c90926dca,1,1%5D=%5Bmozilla-central,dd55da63ebce86ee3867aa3b39975c2a90869ce2,1,1%5D 
it affects some of our talos tests too (the ones running on non-pgo).


We stopped Talos testing of non-e10s builds on May 14, but it looks like 
we also stopped testing Linux PGO builds on May 15. Is that expected?


https://treeherder.mozilla.org/perf.html#/graphs?timerange=5184000=%5Bmozilla-central,80984697abf1f1ff2b058e2d9f0b351fd9d12ad9,1,1%5D=%5Bmozilla-central,f9422672456ec36723cc69e64c10e02cda9dd30f,1,1%5D=%5Bmozilla-central,ff2723032e6bee08807c0d0b082c8c6af3dca6f5,1,1%5D=%5Bmozilla-central,00ab9f9f9241a67f9bfc376910ff8beb2fc0f8d1,1,1%5D=%5Bmozilla-central,f9422672456ec36723cc69e64c10e02cda9dd30f,204160,273383568,1%5D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Chris Peterson]

On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:

On 05/19/2017 02:44 PM, Gregory Szorc wrote:

`mach build` attempts to parse compiler warnings to a persisted
"database."
You can view a list of compiler warnings post build by running `mach
warnings-list`. The intent behind this feature was to make it easier to
find and fix compiler warnings. After all, something out of sight is
out of
mind.


Given that we treat warnings as errors on CI and most directories that 
opt out of warnings-as-errors are third-party code 
(ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to 
make the warning list any more visible. A warning regression in nearly 
all first-party code is already treated as an error.



[1] 
https://searchfox.org/mozilla-central/search?q=ALLOW_COMPILER_WARNINGS=true=moz.build

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

Re: Changing our thread APIs for Quantum DOM scheduling

[Chris Peterson]

The Quantum DOM doc says only content processes will get cooperative 
threading. How will cooperative threading work with multiple content 
processes (e10s-multi)? Will there be inter-process scheduling? For 
example, if content process #1 has one or more foreground tabs (from 
multiple windows) and content process #2 has only background tabs, will 
content process #2 yield to content process #1? Or will content process 
#2 continue to run all of its background tabs because it doesn't know of 
any foreground tabs to prioritize?



On 2017-05-18 4:38 PM, Bill McCloskey wrote:

Hi everyone,

One of the challenges of the Quantum DOM project is that we will soon have
multiple "main" threads [1]. These will be real OS threads, but only one of
them will be allowed to run code at any given time. We will switch between
them at well-defined points (currently just the JS interrupt callback).
This cooperative scheduling will make it much easier to keep our global
state consistent. However, having multiple "main" threads is likely to
cause confusion.

To simplify things, we considered trying to make these multiple threads
"look" like a single main thread at the API level, but it's really hard to
hide something like that. So, instead, we're going to be transitioning to
APIs that try to avoid exposing threads at all. This post will summarize
that effort. You can find more details in this Google doc:

https://docs.google.com/document/d/1MZhF1zB5_dk12WRiq4bpmNZUJWmsIt9OTpFUWAlmMyY/edit?usp=sharing

[Note: I'd like this thread (and the Google doc) to be for discussing
threading APIs. If you have more general questions about the project,
please contact me personally.]

The main API change is that we're going to make it a lot harder to get hold
of an nsIThread for the main thread. Instead, we want people to work with
event targets (nsIEventTarget). The advantage of event targets is that all
the main threads will share a single event loop, and therefore a single
nsIEventTarget. So code that once expected a single main thread can now
expect a single main event target.

The functions NS_GetMainThread, NS_GetCurrentThread, and
do_Get{Main,Current}Thread will be deprecated. In their place, we'll
provide mozilla::Get{Main,Current}ThreadEventTarget. These functions will
return an event target instead of a thread.

More details:

NS_IsMainThread: This function will remain pretty much the same. It will
return true on any one of the main threads and false elsewhere.

Dispatching runnables: NS_DispatchToMainThread will still work, and you
will still be able to dispatch using Get{Main,Current}ThreadEventTarget.

From JS, we want people to use Services.tm.dispatchToMainThread.


Thread-safety assertions: Code that used PR_GetCurrentThread for thread
safety assertions will be converted to use NS_ASSERT_OWNINGTHREAD, which
will allow code from different main threads to touch the same object.
PR_GetCurrentThread will be deprecated. If you really want to get the
current PRThread*, you can use GetCurrentPhysicalThread, which will return
a different value for each main thread.

Code that uses NS_GetCurrentThread for thread safety assertions will be
converted to use nsIEventTarget::IsOnCurrentThread. The main thread event
target will return true from IsOnCurrentThread if you're on any of the main
threads.

Nested event loop spinning: In the future, we want people to use
SpinEventLoopUntil to spin a nested event loop. It will do the right thing
when called on any of the main threads. We'll provide a similar facility to
JS consumers.

Bugs:

Bug 1359903 converted some of our PR_GetCurrentThread assertions to use
NS_ASSERT_OWNINGTHREAD.

Bug 1361561 added GetCurrentPhysicalThread and GetCurrentVirtualThread.
These functions both return a PRThread*. The latter one returns the same
value for all the main threads. It should only be used for assertion
checking.

Bug 1361164 will add the Get{Current,Main}ThreadEventTarget functions.

Bug 1365096 is a metabug to convert all uses of NS_Get{Current,Main}Thread
to use event targets instead. Bug 1365097 is the bug for converting DOM
code.

[1] https://billmccloskey.wordpress.com/2016/10/27/mozillas-quantum-project/



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

Re: Quantum Flow Engineering Newsletter #9

[Chris Peterson]

On 2017-05-12 9:55 AM, Ehsan Akhgari wrote:

This reminded me of
https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and
https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 )

Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking
at the output seems pretty low-effort to find a lot of more
opportunities for this. (Unless I'm misunderstanding things).

Plus, it benefits security!

Yes, this is indeed a good point.  Even though this will really only
have a measurable impact on performance if the functions are called in
hot code, it seems like a shame to not listen to the compiler when it
tells you I could make your code faster if you added this keyword in a
bunch of places.  :-)


Should the Mozilla Coding Style document recommend that all new classes 
use `final` unless they are designed to be derived? It would be a good 
habit even for simple classes that don't derive from a base class.


Also, Herb Sutter recommends [1] that all base classes should either 
have a public virtual destructor or protected non-virtual destructor. 
This prevents the problem where a derived class's non-virtual destructor 
doesn't get called if the object is deleted through a pointer to a base 
class.


So all classes would either:

- be a final class,
- have a public virtual destructor, or
- have a protected non-virtual dtor (possibly an empty inline dtor)


[1] http://www.gotw.ca/publications/mill18.htm
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: QF bug whiteboard tags

[Chris Peterson]

On 2017-05-10 1:05 PM, Jim Mathies wrote:

The quantum flow project has been filing a lot of bugs lately. I'm curious 
about two specific whiteboard tags I've seen - [qf:p1] and [qf], can someone 
explain the differences between these two tags and how this impact the priority 
of these bugs?


Add "[qf]" whiteboard tag to nominate a bug for Quantum Flow triage. The 
"[qf:p1]" whiteboard tag means the bug has been triaged and deemed very 
important (P1).

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

Re: CodeCoverage Monthly Update

[Chris Peterson]

On 2017-05-03 8:44 PM, Kyle Lahnakoski wrote:

  * Daily coverage reports on coveralls.io [1] and on codecov.io[2].
Which do you like?


Does coveralls.io have a top-down coverage view like codecov.io? That 
view seems more useful for both people that want a global view and 
developers that want to drill down into just their component directories.

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

Re: Quantum Flow Engineering Newsletter #6

[Chris Peterson]

btw, Nathan Froyd is working to add Gecko Profiler support for Stylo's 
Rust code and rayon threads in bug 1322656.



On 2017-04-21 8:50 AM, Ehsan Akhgari wrote:

On 04/21/2017 03:12 AM, Nicholas Nethercote wrote:

Judging from the incoming flow of bug reports, the number of people
using the Gecko Profiler has increased in the last week or two. I take
this as a good sign that it's being used increasingly heavily for
Quantum Flow work, which is good.

Yes, indeed.  I should also say that this is definitely due to the hard
work of everyone working on improving it both the backend side and on
the UI side (including you!)  It's safe to say that this push on
performance could not have happened without the Gecko Profiler, so
thanks to everyone who keeps making it better.



Nick

On Fri, Apr 21, 2017 at 4:25 PM, Ehsan Akhgari
> wrote:

Hi everyone,

I would like to share some updates about some of the ongoing
performance related work.

We have started looking at the native stack traces that are
submitted through telemetry from the Background Hang Reports that
take more than 8 seconds.  (We were hoping to have been able to
reduce this threshold to 256ms
 for a while
now, but the road has been bumpy -- but this should land really
soon now!)  Michael Layzell put together a telemetry analysis job
that creates a symbolicated version of this data here:
https://people-mozilla.org/~mlayzell/bhr/
. For example, this
 is the
latest generated report.  The grouping of this data is
unfortunate, since the data is collected based on the profiler
pseudo-stack labels, which is captured after 128ms, and then
native stack (if the hang continues for 8 seconds) gets captured
after that, so the pseudo-stack and the native stack may or may
not correspond, and this grouping also doesn't help going through
the list of native stacks and triage them more effectively.  Work
is under way to create a nice dashboard
 out of this
data, but in the mean time this is an area where we could really
use all of the help that we can get.  If you have some time, it
would be really nice if you can take a look at this data and see
if you can make sense of some of these call stacks and find some
useful bug reports out of them.  If you do end up filing bugs,
these are super important bugs to work on, so please make sure you
add "[qf]" to the status whiteboard so that we can track the bug.

Another item worthy of highlight is Mike Conley's Oh No! Reflow!
add-on .  Don't let the
simple web page behind this link deceive you, this add-on is
really awesome!  It generates a beep every time that a long
running reflow happens in the browser UI (which, of course, you
get to turn off when you don't need to hunt for bugs!), and it
logs the sync reflows that happened alongside the JS call stack to
the code that triggered them, and it also gives you a single link
that allows you to quickly file a bug with all of the right info
in it, pre-filled!  In fact you can see the list of already filed
bugs



through this add-on!

Another issue that I want to bring up is the [qf:p1] bugs.  As you
have noticed, there are a lot of them. :-)  It is possible that
some of these bugs aren't important to work on, for example
because they only affect edge case conditions that affects a super
small subset of users and that wasn't obvious when the bug was
triaged.  In some other cases it may turn out that fixing the bug
requires massive amounts of work that is unreasonable to do in the
amount of time we have, or that the right people for it are doing
more important work and can't be interrupted, and so on.  Whatever
the issue is, whether the bug was mis-triaged, or can't be fixed,
please make sure to raise it on the bug!  In general the earlier
these issues are uncovered the better it is, because everyone can
focus their time on more important work.  I wanted to make sure
that this wasn't lost in all of the rush around our communication
for Quantum Flow, my apologies if this hasn't been clear before.


On to the acknowledgement section, I hope I'm not forgetting to
mention anyone's name here!

  * Bas Schouten made it so that we don't clear the compositor
background immediately before drawing into it
. This
made some painting and scrolling related benchmarks faster

Re: Quantum Flow Engineering Newsletter #5

[Chris Peterson]

On 2017-04-18 4:22 PM, Ehsan Akhgari wrote:

The last time I checked with the graphics
team, at this point it's completely unclear whether Quantum Render is
going to make it, and as such, it's not reasonable for us to depend on
anything that WebRender provides for Photon, because if QR wouldn't make
it to 57 then we wouldn't have a backup plan.


In addition, AFAIK, only about half of Firefox Windows users have GPUs 
that are compatible with WebRender acceleration. We need Photon to 
perform well for users stuck on the software rendering path.

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

Re: e10s-multi on Aurora

[Chris Peterson]

On 2017-04-11 10:31 PM, Salvador de la Puente wrote:

How does this relate with Project Down and the end of Aurora channel? Will
be multi-e10s enabled when shifting from nightly to beta?


There is no connection between Project Dawn and enabling multiple e10s 
content processes in the Aurora channel. e10s-multi is expected to ride 
the trains to release with Firefox 55.




On Wed, Apr 5, 2017 at 1:34 AM, Blake Kaplan  wrote:


Hey all,

We recently enabled 4 content processes by default on Aurora. We're
still tracking several bugs that we are planning to fix in the near
future as well as getting more memory measurements in Telemetry as we
look towards a staged rollout in Beta and beyond.

We were able to turn on in Aurora thanks to a bunch of work from
bkelly, baku, Gabor, and a bunch of other folks.

Here's looking forward to riding more trains!
--
Blake
___
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: Quantum Flow Engineering Newsletter #4

[Chris Peterson]

On 2017-04-07 9:11 AM, Ehsan Akhgari wrote:

   - DOM.  In the DOM team there are several plans and projects under way
   which will hopefully bring various performance improvements to the
   browser.  Probably the largest one is the upcoming plans for cooperative
   scheduling of tasks, which will allow us to interrupt currently executing
   JavaScript on background pages in order to service tasks belonging to
   foreground pages.  You may have seen patches landing as part of a large
   effort to label all of our runnables
   .  This is needed
   so that we can identify how to schedule tasks cooperatively.


Are the bugs to label runnables good for volunteer contributors? Or 
would it be fastest for a DOM expert or engineers from each module to 
rip through the open bugs? Do we need to ask module owners to prioritize 
these bugs? :)


https://bugzilla.mozilla.org/showdependencytree.cgi?id=1321812_resolved=1

According to a searchfox search for unlabeled runnable calls (using the 
function names billm provided), there are still over 800 unlabeled 
runnables:


http://searchfox.org/mozilla-central/search?q=%5CbNS_DispatchTo(Main%7CCurrent)Thread+*%5C(=true=true=
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: windows build anti-virus exclusion list?

[Chris Peterson]

On 3/17/2017 1:45 AM, Honza Bambas wrote:

I have a very similar setup, with even way more exceptions added, but
none of them has the desired effect. Unfortunately, the only way to make
MsMpEng shut up is to disable run-time protection completely for the
time of the build. I think it's a bug in Defender.


Maybe `mach build` can temporarily disable Defender when building?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Sheriff Highlights and Summary in February 2017

[Chris Peterson]

I seem to recall gps saying, a few years ago, that the cost per push or 
Try run was about $36. It would be good to know the current cost so 
developers can feel more comfortable spending Mozilla money on 
"unnecessary" Try runs before landing.



On 3/10/2017 6:47 AM, Andrew Halberstadt wrote:

I don't have any data to back this up, but my suspicion is that a large
percentage
of backouts had try runs, but said try runs didn't run the jobs that failed
and caused
the backout. Imo, these kinds of backouts are (more) acceptable because it
means
the developer was trying to avoid doing a full try run, a practice that
should be
cheaper overall in the long run (and if done properly).

For example, you could either:
A) Do a full try run then push, almost guaranteeing you won't be backed
out. But
then you run every job twice and take longer to complete your bug, a
significant
cost.

B) Do a partial try run, running X% of the jobs yielding a Y% chance of
being
backed out.

There's some sweet spot between no try run, and try: -all which is the most
cost
effective (both in terms of AWS bill and developer time).

That being said, I think this is an issue of tools rather than policy.
Things like being
smarter about running jobs based on files changed and improving interfaces
to
selecting jobs on try, should help with backout rates. But the single
biggest thing we
could do is getting rid of integration branches altogether (and instead get
autoland to
merge directly from try). In this world, backouts would hardly even exist
anymore.

I believe we're already headed in this direction, albeit slowly.

-Andrew

On Fri, Mar 10, 2017 at 8:55 AM, David Burns <dbu...@mozilla.com> wrote:


I went back and did some checks with autoland to servo and the results are
negligible. So from 01 February 2017 to 10 March 2017 (as of sending this
email). I have removed merge commits from the numbers.

Autoland:
Total Servo Sync Pushes: 152
Total Pushes: 1823
Total Backouts: 144
Percentage of backouts: 7.8990674712
Percentage of backouts without Servo: 8.61759425494

Mozilla-Inbound:
Total Pushes: 1472
Total Backouts: 166
Percentage of backouts: 11.277173913


I will look into why, with more pushes, is resulting in fewer backouts. The
thing to note is that autoland, by its nature, does not allow us to fail
forward like inbound without having to get a sheriff to land the code.

I think, and this is my next area to investigate, is the 1 bug per push
(the autoland model) could be helping with the percentage of backouts being
lower.

David

On 7 March 2017 at 21:29, Chris Peterson <cpeter...@mozilla.com> wrote:


On 3/7/2017 3:38 AM, Joel Maher wrote:


One large difference I see between autoland and mozilla-inbound is that

on

autoland we have many single commits/push whereas mozilla-inbound it is
fewer.  I see the Futurama data showing pushes and the sheriff report
showing total commits.



autoland also includes servo commits imported from GitHub that won't

break

Gecko. (They might break the linux64-stylo builds, but they won't be

backed

out for that.)

___
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: Is there a way to improve partial compilation times?

[Chris Peterson]

On 3/7/2017 11:19 AM, Steve Fink wrote:

I have at times spun off builds into their own cgroup. It seems to
isolate the load pretty well, when I want to bother with remembering how
to set it up again. Perhaps it'd be a good thing for mach to do
automatically.

Then again, if dropping the -j count buys you responsiveness for only a
3-5% loss, then perhaps cgroups are not worth bothering with.


Can you just nice mach?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Render builds now on m-c

[Chris Peterson]

Awesome news! Building Quantum Render in mozilla-central and running 
even a subset of our regular tests is a big step towards shipping.


chris


On 2/10/2017 1:11 PM, Kartikaya Gupta wrote:

(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: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Chris Peterson]

On 2/7/2017 1:15 PM, Benjamin Smedberg wrote:

I intend to ship a change which will prevent Flash from loading from file:,
ftp:, or any other URL scheme other than http: or https:.  The purpose of
this change is to increase security and limit Flash to well-tested
configuraitons.


Do you want to also block Flash content from loading file: or ftp: URLs?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: A reminder about MOZ_MUST_USE and [must_use]

[Chris Peterson]

On 1/19/2017 3:13 PM, Nicholas Nethercote wrote:

On Fri, Jan 20, 2017 at 10:01 AM,  wrote:


> And the next step would be to make must-use the default, and have
> MOZ_CAN_IGNORE for the rest. ;-)
>

I actually tried this with all XPIDL methods. After adding several hundred
"Unused <<" annotations for calls that legitimately didn't need to check
the return value -- and I was only a fraction of the way through the
codebase -- I decided that a big bang approach wasn't going to work. So I
then implemented [must_use] as an incremental alternative.


To encourage all new XPIDL methods to use must_use, could you add 
MOZ_MUST_USE to the C++ macro definition of NS_IMETHOD and rename all 
the existing uses of NS_IMETHOD to something like 
NS_IMETHOD_RESULT_OPTIONAL or NS_IMETHOD_RESULT_UNUSED? Developers 
adding new methods will reach the familiar (and shorter) NS_IMETHOD 
macro and get must_use for free.

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

Re: Intent to Implement and Ship: Large-Allocation Header

[Chris Peterson]

On 1/18/2017 12:21 PM, Michael Layzell wrote:

Games implemented on the web platform using WASM or asm.js use large
contiguous blocks of allocated memory as their backing store for game
memory. For complex games, these allocations can be quite large, sometimes
as large as 1GB. In 64-bit builds, we have no problem finding a large
enough section of virtual memory that we can allocate a large contiguous
hunk. Unfortunately normal use of Firefox quickly fragments the smaller
address space of 32-bit Firefox, meaning that these complex games often
fail to run.


If 64-bit Firefox doesn't have WASM OOM problems, will we still support 
the Large-Allocation header on 64-bit?

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

Re: Intent to unship: navigator.getBattery (Battery Status API)

[Chris Peterson]

WebKit implemented the battery API, though Safari didn't expose the API 
to web content. Yesterday the WebKit team proposed removing the API, too:


https://bugs.webkit.org/show_bug.cgi?id=164213

https://lists.webkit.org/pipermail/webkit-dev/2016-October/028468.html


On 10/31/2016 1:24 AM, Chris Peterson wrote:

As proposed earlier on the dev-platform list [1], I made the Battery
Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The
battery code and tests remain, available to Gecko code and Firefox add-ons.

There should be little risk of web compat regressions. The battery API
was never implemented by IE, Edge, or Safari, so web content should
already be feature-detecting the API. Also, I know of no non-trivial
websites using the API for anything other than fingerprinting users in
the four years since Firefox introduced the API in 2012 (Firefox 10
[3]). Chrome added support in 2014.

We always have the option to make the API available to web content again
if a website or app demonstrates an interesting use case using Chrome's
battery API. However, I feel the supposed use cases for the battery API
would be better served by something like a lifecycle event API that
includes low battery/memory warnings. That would expose less identifying
information and allow the user and UA to customize the lifecycle settings.


[1]
https://groups.google.com/d/msg/mozilla.dev.platform/5U8NHoUY-1k/9ybyzQIYCAAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1313580
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=678694


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

Re: Intent to unship: navigator.getBattery (Battery Status API)

[Chris Peterson]

On 10/31/2016 11:23 AM, nicjan...@gmail.com wrote:

Boomerang is an open-source library [1] for collecting performance telemetry.  
You're correct that it currently captures the battery level and other device 
characteristics.  While Boomerang was not designed for the purpose of 
fingerprinting users, it captures many performance metrics and page 
characteristics on the beacon.  Boomerang also only captures battery level, not 
charging time/discharging time (which we understand to be needed for the 
fingerprinting case).  mPulse RUM itself (which is one of the services that 
utilizes Boomerang) does not do user fingerprinting -- we capture all of this 
data to look at aggregate performance.

Boomerang has been collecting the battery level in supported browsers for a 
while, but we don't consider it an essential device characteristic.  In 
aggregate, it becomes interesting -- we can tell, for example, if certain paths 
through a customer's website correlate with high battery discharge, indicating 
possible post-page-load performance issues (like too many ads).


Thanks for the explanation of Boomerang. I see how battery level would 
be an interesting data point for RUM. I don't know if the battery 
measurements would be precise enough for short browsing sessions to be 
actionable, though it might be interesting to exclude low-battery users 
as outliers with non-representative system performance. :)


Have you seen any such correlations?

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

Intent to unship: navigator.getBattery (Battery Status API)

[Chris Peterson]

As proposed earlier on the dev-platform list [1], I made the Battery 
Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The 
battery code and tests remain, available to Gecko code and Firefox add-ons.


There should be little risk of web compat regressions. The battery API 
was never implemented by IE, Edge, or Safari, so web content should 
already be feature-detecting the API. Also, I know of no non-trivial 
websites using the API for anything other than fingerprinting users in 
the four years since Firefox introduced the API in 2012 (Firefox 10 
[3]). Chrome added support in 2014.


We always have the option to make the API available to web content again 
if a website or app demonstrates an interesting use case using Chrome's 
battery API. However, I feel the supposed use cases for the battery API 
would be better served by something like a lifecycle event API that 
includes low battery/memory warnings. That would expose less identifying 
information and allow the user and UA to customize the lifecycle settings.



[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/5U8NHoUY-1k/9ybyzQIYCAAJ

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1313580
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=678694
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing navigator.buildID?

[Chris Peterson]

On 10/30/2016 2:27 AM, Pascal Chevrel wrote:

IMO the builID is important for our community of nightly testers that
report bug and need to indicate precisely in which build they found a
regression, so keeping that information available via about:support and
extensions such as Nightly Testers Tools seems valuable for mozilla to
me in a chrome context.


Limiting navigator.buildID to chrome context is a simple change: just 
add the "ChromeOnly" annotation to buildID's webidl [1] and fix any 
fallout like DOM test [2].


However, the Gecko Media Playback team and Netflix still use buildID 
(collected by Netflix's video player JavaScript) to identify regressions 
and verify bug fixes. I believe they mostly watch the Firefox Beta 
channel (because there are too few Netflix customers on Nightly and Dev 
Edition) to verify bug fixes. We could limit buildID to pre-release 
channels, but those channels are where buildID exposes the most unique 
entropy (because every day's build has a new buildID). All Firefox 
Release channel users (for a given OS and Firefox dot-release) have the 
same buildID.


Alternately, buildID could be hidden behind a domain whitelist pref, 
seeded with sites working with Mozilla. If you are, say, a Netflix 
customer, they already know who you are, so exposing your buildID to 
them is not much of a tracking risk. :)



[1] 
http://searchfox.org/mozilla-central/source/dom/webidl/Navigator.webidl#187
[2] 
http://searchfox.org/mozilla-central/source/dom/tests/mochitest/bugs/test_bug351601.html#24

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

Re: Removing the Battery Status API?

[Chris Peterson]

On 10/26/2016 9:21 AM, Boris Zbarsky wrote:

So I decided to see what sites were doing with it.  I set a breakpoint
in getBattery() and tried browsing.  The first site I tried loading was
cnn.com, and it hit the breakpoint.  It's hitting it because it's using
the "boomerang" library from https://github.com/yahoo/boomerang (or one
of its various clones) as far as I can tell, and
https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/memory.js#L177-L203
pokes at the battery API.  Looks like it reports the battery level as
part of its telemetry?  The original commit that introduces that is
https://github.com/yahoo/boomerang/commit/b0c41b144913338ea905f03fc28f32130c5521e5
which is not terribly informative as to _why_ that data is being collected.


Thanks, Boris. That's a great analysis.

Boomerang reporting users' battery levels, hardwareConcurrency, and 
maxTouchPoints sounds like active fingerprinting (what the library calls 
"beaconing"). Boomerang also extracts third-party tracking IDs from 
Google, Adobe, and IBM analytics cookies:


https://github.com/yahoo/boomerang/blob/b70cb237c175debf1fda31ab9ae44e1cfa7996ca/plugins/third-party-analytics.js


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

Removing the Battery Status API?

[Chris Peterson]

What is the use case for the Battery Status API [0], 
navigator.getBattery()? Can we remove the Battery API or perhaps 
restrict it to non-web content like browser extensions or privileged web 
apps? Chrome and Firefox support the Battery API, but neither Edge nor 
WebKit have signaled an intent to implement it [3].


In theory, web developers would use the Battery API to save document 
data before the battery dies, to ease off heavy computation when the 
battery is low, or to implement the Firefox OS settings app. The real 
world use cases, however, seem to be fingerprinting users [1] and 
inflating Uber prices for desperate users with low batteries [2]. Can 
anyone point to a real website using the Battery API for a legitimate 
purpose?


The BATTERY_STATUS_COUNT probe [4] reports over 200M battery API calls 
for Firefox 49. The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE probe 
[5] reports that 6% of web pages use the Battery API, IIUC. That seems 
surprisingly high given the few legitimate use cases. (Could that 
counter be inadvertently triggered by web content that simply enumerates 
the navigator object's properties without actually calling 
navigator.getBattery()?)


I have a patch that makes the Battery API chrome-only and fixes the 
web-platform tests.


[0] https://developer.mozilla.org/en-US/docs/Web/API/Battery_Status_API
[1] 
http://randomwalker.info/publications/OpenWPM_1_million_site_tracking_measurement.pdf

[2] http://www.forbes.com/sites/amitchowdhry/2016/05/25/uber-low-battery/
[3] https://www.chromestatus.com/feature/4537134732017664
[4] https://mzl.la/2eDFvbR
[5] https://mzl.la/2eDG4Cj
[6] https://mzl.la/2eKcZ6d
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Chris Peterson]

On 10/25/2016 11:43 AM, Eric Rescorla wrote:

Setting aside the policy question, the location API for mobile devices
generally
gives a much more precise estimate of your location than can be obtained
from the upstream network provider. For instance, consider the case of the
ISP upstream from Mozilla's office in Mountain view: they can only localize
a user to within 50 meters or so of the office, whereas GPS is accurate to
a few meters. And of course someone who is upstream from the ISP may just
have standard geo IP data.


Assuming every MITM and website already has approximate geo IP location, 
we could fuzz the navigator.getCurrentPosition() result for HTTP sites. 
That would leak no more information than passive geo IP and would not 
break HTTP websites using the geolocation API.

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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Chris Peterson]

On 10/25/2016 6:26 AM, Ehsan Akhgari wrote:

FWIW, and to the extent that my opinion matters on the topic, I strongly
disagree that breaking the websites that people use silently is the
right thing to do.

Let's ignore the HTTPS Everywhere part of the thread, and instead pay
more attention to what our users will see after we roll this out.  It's
easy to ignore this when looking at the ratio of granted non-secure
geolocation prompts per all page loads, but we _are_ talking about
breaking a fifth of geolocations on the web for our users.


I strongly agree with Ehsan that breaking a fifth of geolocation 
requests is a bad user experience.


What is the threat model for geolocation over HTTP? That a coffee shop, 
ISP, or Big Brother will MITM a non-secure site so as to sniff a user's 
location? To reduce location leaks without breaking non-secure 
geolocation, perhaps we could always require door hanger permission for 
geolocation requests on HTTP sites?


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

Re: Intent to restrict to secure contexts: navigator.geolocation

[Chris Peterson]

On 10/21/2016 3:11 PM, Tantek Çelik wrote:

> Does this mean that we'd be breaking one in 5 geolocation requests as a
> result of this?  That seems super high.  :(

Agreed. For example, my understanding is that this will break
http://www.nextbus.com/ (and thus http://www.nextmuni.com/ ) location
awareness (useful for us SF folks), which is kind of essential for
having it tell you transit stops near you. -t


Indeed, the geolocation feature on nextbus.com is broken in Chrome. (The 
site shows a geolocation error message on first use.)


Next Bus already has an HTTPS version of their site, but it is not the 
default and has some mixed-content warnings. For a site that uses 
geolocation as a core part of its service, I'm surprised they have let 
it stay broken in Chrome for six months. Chrome removed insecure 
geolocation in April 2016 and announced its deprecation in November 2015.

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

Increasing usage of 64-bit Firefox on Windows

[Chris Peterson]

Matt Howell will soon land stub installer support for 64-bit Windows in 
Nightly 52 (bug 797208), as part of an effort to move more Firefox users 
to 64-bit. About 66% of our Windows users are running 32-bit Firefox on 
64-bit Windows. They're missing out on potential optimizations and fewer 
OOM crashes from 64-bit Firefox.


Matt's change will only add 64-bit support to the stub installer, not 
the Firefox updater. We will look into upgrading existing 32-bit Firefox 
users to 64-bit next year (bug 1274659).


The stub installer will automatically select 32- or 64-bit Firefox 
depending on the user's system configuration. Our proposed system 
requirements to receive 64-bit by default are: 64-bit Windows 7/8/8.1/10 
with at least 2 GB RAM. Users can manually override the default and 
choose 32- or 64-bit on the stub installer's Options page. We don't plan 
to support 64-bit XP or Vista.


64-bit should significantly reduce OOM crashes, always top crash #1 or 
#2 for 32-bit Firefox on the Beta and Release channels. The following 
re:dash query is a preview of the improved crash stats from 64-bit. Note 
that this query may exaggerate 64-bit's benefit. We should compare 32- 
and 64-bit Firefox both on 64-bit Windows, but this query doesn't 
distinguish between 32-bit Firefox running on 32-bit or 64-bit Windows. 
32-bit Firefox has a 4 GB virtual address space on 64-bit Windows and is 
less likely to OOM than on 32-bit Windows, where it has a 2 GB virtual 
address space.


Browser, content, and plugin process crashes/kilohour for Firefox 48 
(Beta + Release):


  32-bit Firefox:  3.762.1511.37
  64-bit Firefox:  3.221.320.39

  https://sql.telemetry.mozilla.org/queries/1238#table

Flash and Silverlight are the only NPAPI plugins we have supported on 
64-bit Firefox. We have waited until Firefox 52 to roll out 64-bit to 
more users because we didn't want to regress users' plugin support. 
Firefox 52 is disabling support for all NPAPI plugins other than Flash 
(bug 1269807), so 64-bit's limited plugin support is no longer any 
regression compared to 32-bit.



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

Re: Removal of B2G from mozilla-central

[Chris Peterson]

On 9/29/2016 11:46 AM, Sebastian Hengst wrote:

as has been announced earlier
https://groups.google.com/forum/#!topic/mozilla.dev.fxos/FoAwifahNPY the
Boot 2 Gecko (B2G) code will be removed from mozilla-central.


Is Gonk used anywhere besides B2G? Can we remove all Gonk code, e.g. 
dom/camera/Gonk* and #ifdef MOZ_WIDGET_GONK?

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

Re: Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

[Chris Peterson]

On 8/17/2016 5:03 PM, Karl Dubost wrote:

Chris,

Le 18 août 2016 à 02:21, Chris Peterson <cpeter...@mozilla.com> a écrit :

Here is a status report from the Chrome team about their current and future 
"interventions":
https://docs.google.com/document/d/1vqM_Dbi-V7LtdOwb2IGjgor9Fvl5k_FvO2DJGr4CaSQ/
An intervention is when a user agent decides to deviate slightly from a 
standardized behavior in order to provide a greatly enhanced user experience.

Very cool information. Two thoughts.

1. What is the status report about Firefox "interventions"


AFAIK, we don't have a coordinated plan for interventions. I know we 
have already shipped some iframe and timer throttling and we are now 
testing blocking of non-essential plugin content in Beta 49:


https://blog.mozilla.org/futurereleases/2016/07/20/reducing-adobe-flash-usage-in-firefox/



2. What are the impact of the Chrome "interventions" on Firefox Web 
compatibility (aka if they change the behavior and developers adjust to the new black, 
will it break in Firefox).


The following presentation from the Chrome team's BlinkOn 6 talks about 
some of the behavior changes and some of their decision-making process 
when designing interventions. One unfortunate example, advertisers 
worked around Chrome for Android's "do not autoplay mobile videos" 
intervention by deploying pseudo-video ads using canvas-based video 
codecs, which was worse for bandwidth and power usage.


https://youtu.be/wQGa_6CRc9I


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

Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

[Chris Peterson]

Here is a status report from the Chrome team about their current and 
future "interventions":


https://docs.google.com/document/d/1vqM_Dbi-V7LtdOwb2IGjgor9Fvl5k_FvO2DJGr4CaSQ/

An intervention is when a user agent decides to deviate slightly from a 
standardized behavior in order to provide a greatly enhanced user 
experience. An important part of every intervention is closing the 
feedback loop and educating developers about the new behavior, so that 
they can respond appropriately.


- Rendering pipeline throttling for offscreen cross-origin frames
- Disallow pop-ups from cross-origin frames on non-tap touch events
- Unintervention: re-instate autoplay for muted/silent videos
- Bail out on web fonts with an effectively slow connection
- Throttle the JS timers of offscreen frames
- Blocking perf-taxing document.write for users on 2G
- Scroll anchoring
- Disable the Vibrate API for cross origin frames
- Only allow navigations/popups from cross-origin frames on click
- History back that works!
- Ignore clicks on iframes that have moved in the last XXms
- Project OldSpice: taming annoyances with JS dialogs
- Make touchstart during a fling uncancelable
- Lower loading priority / or not loading offscreen cross origin iframes
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reproducible builds

[Chris Peterson]

On 7/18/16 11:56 AM, Gregory Szorc wrote:

A significant obstacle to even comparable builds is "private" data embedded
within Firefox. e.g. Google API Keys. I /think/ we're also shipping some
DRM blobs.


Mozilla does not ship any DRM blobs with Firefox. The Adobe Primetime 
and Google Widevine CDMs (DRM DLLs) are downloaded from Adobe and Google 
servers on Firefox first-run. Similarly, Cisco's OpenH264 codec is 
downloaded from a Cisco server on Firefox first-run.

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

Re: The Whiteboard Tag Amnesty

[Chris Peterson]

On 6/8/16 4:03 PM, Jason Duell wrote:

Could we dig into details a little more here?  I assume we could add a
database index for the whiteboard field if performance is an issue.
Do we give keywords an enum value or something (so bugzilla can
index/search them faster)?  I'm not clear on what a "real tag system" means
concretely here.


Most whiteboard fields are fairly structured, with people using [words 
in brackets] or words-with-dashes to group terms. Indexing by all word 
or just pseudo keywords (using brackets or dashes) seems straightforward.


It would be interesting to see a ranked list of the most popular 
whiteboard words. Those would be good candidates for keywords.

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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Chris Peterson]

On 5/30/16 11:22 PM, Nicholas Nethercote wrote:

#2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument
given. These are mostly OOMs, though there are a few others in there.
These ones should be annotated so they show up separately.


MOZ_CRASH()'s explanation string parameter is optional. Should it be 
required? There are 998 calls in mozilla-central to MOZ_CRASH() without 
an argument, so annotating all of these won't happen overnight.

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Chris Peterson]

Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit 
Firefox. Streaming video services will likely move their Firefox users 
from Silverlight to Widevine this year, so Silverlight usage will 
decline by EOY.



On 5/12/16 1:10 PM, Ryan VanderMeulen wrote:

Flash installs the 32-bit and 64-bit plugin versions side by side
already (in System32 and SysWOW64, respectively), so I don't think
that's an issue here.

-Ryan

On 5/12/2016 3:38 PM, Lawrence Mandel wrote:

Do we need this criteria?

RAM - Does it hurt to move an instance that has <4GB?
NPAPI - We've announced that we'll remove support this year [1].
Should we
just wait until we do? Do we have a solution for Flash on Win64 that
makes
this viable?

Lawrence

[1]
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/


On Thu, May 12, 2016 at 3:12 PM, Ben Hearsum 
wrote:


This is a slight change from the current model where we purposely
make the
client very dumb, and make the decision on the server (to minimize the
possibility of client-side bug making updates impossible). However, this
doesn't seem like a case where we could get somebody stuck very
easily, and
I don't see a practical way of making the decision on the server if it
requires this much information.

On 2016-05-12 01:07 PM, Ted Mielczarek wrote:


I suspect we'd want to add some extra token like "it's ok to update
this
32-bit build to a 64-bit build", and have all the gating logic live on
the client-side. Odds are if we want to change the criteria we'd
have to
change the client anyway.

-Ted

On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote:


Do you have thoughts on how we'll be able to serve the users the
correct
build if we have to base the decision on plugins they may have or
other
information that's not in the update ping? We can already detect
32-bit
builds on 64-bit Windows through the build target, but information
about
plugins or RAM is not something we know about when serving updates.

On 2016-05-12 11:45 AM, Ted Mielczarek wrote:


Hello,

Given all the discussion around SSE[2] lately, I was curious as to
whether we had made any plans to update Windows users that are
running
32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows
builds. The 64-bit Windows builds do use SSE2, since that's a
baseline
requirement for x86-64 processors, and the overall performance should
generally be better (modulo memory usage, I'm not sure if we have an
exact comparison). Additionally 64-bit builds are much less likely to
encounter OOM crashes due to address space fragmentation since
they have
a very large address space compared to the maximum 4GB available
to the
32-bit builds.

It does seem like we'd need some minimal checking here, obviously
first
for whether the user is running 64-bit Windows, but also possibly
whether they use 32-bit plugins (until such time as we unsupport
NPAPI).
32-bit plugins will not work on a 64-bit Windows Firefox (we do
not have
the equivalent of Universal binaries like we do on OS X).

-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





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

Re: libstdc++ debug mode enabled in debug builds

[Chris Peterson]

Similarly, quite a few third-party libraries do not use the standard 
DEBUG and assert() macros. When integrating new third-party code, be 
sure to check whether you must define any extra macros to enable 
assertions in debug builds.


For example, to enable assertions in the ffvp9 decoder, we had to 
#define ASSERT_LEVEL 2:


https://hg.mozilla.org/mozilla-central/rev/e475e587c448#l1.34


On 5/11/16 4:19 PM, Nathan Froyd wrote:

libstdc++ has a "debug" mode:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html

which adds checks for iterator safety and algorithm preconditions.
Bug 1270832, recently landed on inbound, turns this mode on for debug
builds via our wrapped C++ headers.  Please file a bug if you find
that debug mode is not getting turned on when you think it should.

Safer hacking,
-Nathan


___
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

[Chris Peterson]

On 5/5/16 8:23 PM, sfbay.mapfi...@gmail.com wrote:

The best option, from my perspective (supporting a wide array of users, OS 
versions, hardware), is to make the final 10.6-10.8 version be (or become) the 
next ESR with a startup page providing them with the choice and action 
buttons/links.


Making the upcoming final 10.6–10.8 release (Firefox 47?) an ESR is an 
interesting idea. It's a unfortunate that ESR 45 was just released. 
Enterprises may already be deploying ESR 45 and not want to test and 
deploy another ESR so soon.

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

Re: Reverting to VS2013 on central and aurora

[Chris Peterson]

On 5/5/16 9:26 PM, Gregory Szorc wrote:

I'll try to stand up automation to ensure central remains buildable with
VS2015. This will add extra work and strain on automation and likely make
writing C++ that remains compatible with multiple Visual Studio versions
slightly harder. This is unfortunate, but I think necessary since people
will want to use VS2015 for development.


Can we continue to build Windows x64 with VS2015? That would ensure code 
is still buildable with VS2015, take advantage of newer optimizations 
and warnings, and have little (?) infrastructure overhead compared to 
using VS2013.

___
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

[Chris Peterson]

On 5/3/16 3:11 AM, Xidorn Quan wrote:

> Then we should plan to drop Universal builds in the same release,
> because without supporting 10.6 or 32-bit NPAPI plugins, the 32-bit half
> of the build is just cruft.


That doesn't mean we can't remove 32-bit NPAPI support on OS X sooner 
than 53. Most enterprises are probably using Windows and not 32-bit OS X.


bsmedberg's OS version dashboard (for Firefox 42 in November 2015) says 
only 1.4% of OS X users were running 32-bit Firefox. btw, 16.5% of OS X 
users were still running 10.6.


http://bsmedberg.github.io/telemetry-dashboard/new-pipeline/active-weekly.html



Is there a bug tracking NPAPI removal?


No, so I just filed bug 1269807 (Bugzilla alias "remove-npapi"). Feel 
free to add relevant blocking or blocked bugs.




Once we drop Silverlight support on OS X, we can fix bug 846566 \o/


Thanks. I made the "remove-npapi" bug block bug 846566 as a reminder.
___
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

[Chris Peterson]

On 5/2/16 5:18 PM, Gregory Szorc wrote:

On Mon, May 2, 2016 at 5:12 PM, Chris Peterson <cpeter...@mozilla.com>
wrote:


On 5/2/16 4:10 PM, Gregory Szorc wrote:


So where does that leave us on Universal OS X builds? IIRC our blocker is
the need to support 32-bit Silverlight in the plugin container so various
streaming services using it don't break. Where are we on that front?
(Reminder: killing Universal OS X packages will make automation builds
significantly faster and will reduce the DMG size by almost half.)



I don't know the status of 32-bit Silverlight on OS X, but we're shipping
Widevine support in Firefox 47 (for Windows 7+ and OS X 10.6+). Streaming
services will have an easy migration path from Silverlight to their
existing Widevine player code.

That said, I don't expect the long-tail of streaming services to complete
this transition before the end of 2016, when we already plan to drop NPAPI
plugins.



Fair enough.

So what's the last Firefox release to support NPAPI plugins? 50? 51?


We're tentatively planning to remove NPAPI support (for plugins other 
than Flash) in 53 because 52 is the next ESR. We'd like ESR 52 to 
support NPAPI as a transition option for enterprise users that rely on Java.


___
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

[Chris Peterson]

On 5/2/16 4:10 PM, Gregory Szorc wrote:

So where does that leave us on Universal OS X builds? IIRC our blocker is
the need to support 32-bit Silverlight in the plugin container so various
streaming services using it don't break. Where are we on that front?
(Reminder: killing Universal OS X packages will make automation builds
significantly faster and will reduce the DMG size by almost half.)


I don't know the status of 32-bit Silverlight on OS X, but we're 
shipping Widevine support in Firefox 47 (for Windows 7+ and OS X 10.6+). 
Streaming services will have an easy migration path from Silverlight to 
their existing Widevine player code.


That said, I don't expect the long-tail of streaming services to 
complete this transition before the end of 2016, when we already plan to 
drop NPAPI plugins.

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