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: 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: 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: All the processes

[Chris Peterson]

On 3/3/2017 4:15 PM, Nicholas Nethercote wrote:

- plugin process: just for Flash now?


On 32-bit Windows, there are multiple plugin processes because Firefox 
runs Flash in a plugin process and then Flash spawns one (or more?) of 
its own "Protected Mode" processes. IIUC, the Protected Mode processes 
are locked down tighter and broker file access/etc through the main 
plugin process.

___
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: Sheriff Highlights and Summary in February 2017

[Chris Peterson]

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

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  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  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: 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: 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&hide_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(&case=true®exp=true&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 #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: 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
mailto:ehsan.akhg...@gmail.com>> 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: 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: 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: 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: 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: 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&case=true&path=moz.build

___
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&series=%5Bmozilla-central,80984697abf1f1ff2b058e2d9f0b351fd9d12ad9,1,1%5D&series=%5Bmozilla-central,ae68c64ef8bfa104fded89971f1c2c6c90926dca,1,1%5D&series=%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&series=%5Bmozilla-central,80984697abf1f1ff2b058e2d9f0b351fd9d12ad9,1,1%5D&series=%5Bmozilla-central,f9422672456ec36723cc69e64c10e02cda9dd30f,1,1%5D&series=%5Bmozilla-central,ff2723032e6bee08807c0d0b082c8c6af3dca6f5,1,1%5D&series=%5Bmozilla-central,00ab9f9f9241a67f9bfc376910ff8beb2fc0f8d1,1,1%5D&selected=%5Bmozilla-central,f9422672456ec36723cc69e64c10e02cda9dd30f,204160,273383568,1%5D
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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: 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: Profiling nightlies on Mac - what tools are used?

[Chris Peterson]

On 6/20/17 10:28 AM, Ehsan Akhgari wrote:
That seems like the obvious next step to investigate to me.  We should 
*really* only talk about stripping builds as the last resort IMO, since 
we have way too many developers using OSX every day...


Does profiling an unstripped Mac build still produce useful results if 
the unstripped builds are slower than the stripped builds we ship to users?

___
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: 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&view=breakdown&suite=speedometer-misc
___
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: 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

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

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: 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

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 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: 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

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: 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

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

[Chris Peterson]

Correction to my earlier claims about our minimum memory requirement.

The stub installer will default to 64-bit for users with >= 1800 MB. So 
users with exactly 2 GB should get 64-bit Firefox. Only Win64 users with 
strictly less than 2 GB will default to 32-bit Firefox.


Why the magic number 1800 MB? The Windows API we use to query the 
machine's available memory omits physical memory reserved for hardware 
drivers, which is typically a couple hundred KB. So most "2 GB" machines 
will report less than 2048 MB available memory.


Stub installer's memory check:
https://searchfox.org/mozilla-central/source/browser/installer/windows/nsis/stub.nsi#189-195


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.


Nick

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


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

On Thu, Jul 20, 2017 at 10:42 AM, Chris
Petersonmailto: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 <mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-platform
<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-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 
wrote:


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


On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson
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: 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&key=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&key=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&filter-searchStr=ccov


[1b] Example on TH: 
https://treeherder.mozilla.org/#/jobs?repo

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&A 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: 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 
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: 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: 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: 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 :

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: 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: 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: 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()&case=true®exp=true&path=.c
___
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: 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: 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: 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: 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

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

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

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

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: 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: 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: 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&q=-moz-appearance+menulist-button&type=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&q=-moz-appearance+button-bevel&type=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 

Fingerprinting of battery status?

[Chris Peterson]

What is a legitimate use case for a web page to know my battery status? 
Battery level and time remaining can be used to fingerprint users.


A mobile webapp might use battery level to throttle its activity, but 
that could be something the OS handles by pausing or throttling apps 
directly or broadcasting app lifecycle events. I can't think of a good 
reason why a web page in a browser, especially on a desktop OS, needs to 
know anything about my battery.


http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life

http://eprint.iacr.org/2015/616.pdf


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

Rewriting YouTube's Flash video embedding code to use HTML video?

[Chris Peterson]

Does Gecko have a precedent for rewriting certain HTML patterns? YouTube 
is migrating from Flash to HTML video, but many third-party websites 
copied YouTube's old example code to embedded Flash videos. YouTube's 
current embedding code automatically switches between Flash and HTML 
video, but YouTube can't fix third-party websites still using the old 
embedding code.


Bug 769117 discusses whether Gecko should detect YouTube's old embedding 
boilerplate and automatically rewrite it to use the current code. 
Firefox and Safari extensions [1] [2] already do this, but should Gecko 
include this feature directly? It would improve users' video experience 
and fix dead links if/when Firefox or YouTube stop supporting Flash. 
OTOH, this is a site-specific workaround and thus might not belong in 
Gecko itself.



chris

[1] https://github.com/hfiguiere/no-flash/
[2] http://clicktoflash.com/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rewriting YouTube's Flash video embedding code to use HTML video?

[Chris Peterson]

On 8/21/15 4:31 PM, Hubert Figuière wrote:

Disclaimer: I wrote the Firefox add-on mentioned, and I filed the bug
mentioned as well. So my opinion is sorta made.


Yes, thank you! :)



On 21/08/15 06:17 PM, Chris Peterson wrote:

Does Gecko have a precedent for rewriting certain HTML patterns? YouTube
is migrating from Flash to HTML video, but many third-party websites
copied YouTube's old example code to embedded Flash videos. YouTube's
current embedding code automatically switches between Flash and HTML
video, but YouTube can't fix third-party websites still using the old
embedding code.

Bug 769117 discusses whether Gecko should detect YouTube's old embedding
boilerplate and automatically rewrite it to use the current code.
Firefox and Safari extensions [1] [2] already do this, but should Gecko
include this feature directly? It would improve users' video experience
and fix dead links if/when Firefox or YouTube stop supporting Flash.
OTOH, this is a site-specific workaround and thus might not belong in
Gecko itself.


It think that it is a feature that could be implemented in Firefox:

1. make it so that the rules are rewritable without updating the
browser, or at least touching the core. ESR comes to mind as a reason
why we'd love to update these.

2. make it cross platform. Mobile (including FirefoxOS) would completely
benefit from that. Case in point, Safari on iOS has been doing that for
a very long time.


Do you know what Safari is rewriting? I assume it's more than just Flash 
videos.




3. don't make it specific to YouTube but specific to Flash. no-flash
supports Dailymotion (the French YouTube) and Vimeo (rarer since they
have done HTML5 embed for even longer). With 1. we can add rules easily.

As for the question if Gecko has a feature, maybe that's where we
implement it. I'm not sure if that's a feature to expose in the wild or
not but given that we can do it with add-ons, and there are a few
concrete use cases, we can possibly think of making this of general
usefulness.


Good point. It could be a general pattern-matching/rewriting API 
available to add-ons. Regular expressions are part of the reason Adblock 
Plus is slow. We could move that matching into native code.



chris


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

Re: Rewriting YouTube's Flash video embedding code to use HTML video?

[Chris Peterson]

On 8/24/15 9:43 AM, Ehsan Akhgari wrote:

We have done a site specific workaround in the past for hotmail that we
almost shipped , so
there is prior art here.

I think that for the specific case at hand, it does make sense to add a
site-specific workaround, since I think that the user facing benefit
trumps the technical purity.


Thanks. I'll take a look. We're working with YouTube and they see these 
third-party sites as a problem, too.


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

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

[Chris Peterson]

On 8/30/15 5:53 PM, Nicholas Nethercote wrote:

I just landed the patches in bug 1198334 that do exactly that. The option has
also changed name and is now called ALLOW_COMPILER_WARNINGS. (If you're
wondering why I changed the name, it's because it's easier in mozbuild to have
an option that defaults to False than to True.)


\o/ yeah!



- About half of those 79 are in third-party code that we do not control (i.e.
   we regularly update from upstream), for which the option will always be
   necessary. There may also be some third-party directories in which I didn't
   add ALLOW_COMPILER_WARNINGS because it wasn't currently necessary, but where
   it may become necessary if future updates introduce new warnings.


Should we hold third-party code to the same warning levels as Mozilla's 
home-grown code? When we find warnings in third-party code, we typically 
just suppress them because they weren't serious issues and fixing them 
upstream is extra work. Sometimes upstream doesn't care or want the fixes.


In other projects I've worked on, such as closed-source commercial 
projects or Chromium, third-party code has been "quarantined" in a 
top-level vendor directory (called something like "third_party" [1]). 
Having third-party code in one directory improves modularity and makes 
it easier to audit code licenses and to identify and update outdated 
libraries. In contrast, mozilla-central has third-party libraries 
sprinkled throughout the tree and each library uses its a different 
update process or script. It would be nice to share a common process and 
script.



chris


[1] https://chromium.googlesource.com/chromium/src.git/+/master/third_party/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The opt-in FAIL_ON_WARNINGS has been replaced with the opt-out ALLOW_COMPILER_WARNINGS

[Chris Peterson]

On 8/31/15 11:54 AM, Ted Mielczarek wrote:

On Mon, Aug 31, 2015, at 01:47 PM, Chris Peterson wrote:

>Should we hold third-party code to the same warning levels as Mozilla's
>home-grown code? When we find warnings in third-party code, we typically
>just suppress them because they weren't serious issues and fixing them
>upstream is extra work. Sometimes upstream doesn't care or want the
>fixes.

This is hard because it means that pulling in an update from upstream
can lead to bustage that needs to be fixed. I've hit this when updating
Breakpad before and it adds an extra layer of annoyance to an already
annoying update process. We can certainly try to upstream warning fixes,
but we shouldn't make life harder for ourselves either.


When I said we have typically suppressed third-party warnings, I meant 
with CXXFLAGS += ['-Wno-whatever'] in moz.build, not modifying 
mozilla-central's snapshot of the third-party code. I do not think we 
should modify third-party code without an in-tree patch file or 
upstreaming the fix.


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

Updates to Chrome platform support

[Chris Peterson]

http://chrome.blogspot.com/2015/11/updates-to-chrome-platform-support.html

* Chrome’s support for Windows XP will be extended from December 2015 to 
April 2016 (after previously extending from April 2015 to December 2015).


* Chrome will also drop support for Windows Vista and Mac OS X 10.6, 
10.7, and 10.8 in April 2016. "Chrome will continue to function on these 
platforms but will no longer receive updates and security fixes."


What is Mozilla's current plan for supporting XP, Vista, and OS X 10.6–10.8?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updates to Chrome platform support

[Chris Peterson]

btw, I reposted this on the firefox-dev mailing list because people on 
IRC thought that was a more appropriate forum:


https://mail.mozilla.org/pipermail/firefox-dev/2015-November/003523.html


On 11/10/15 1:37 PM, Chris Peterson wrote:

http://chrome.blogspot.com/2015/11/updates-to-chrome-platform-support.html

* Chrome’s support for Windows XP will be extended from December 2015 to
April 2016 (after previously extending from April 2015 to December 2015).

* Chrome will also drop support for Windows Vista and Mac OS X 10.6,
10.7, and 10.8 in April 2016. "Chrome will continue to function on these
platforms but will no longer receive updates and security fixes."

What is Mozilla's current plan for supporting XP, Vista, and OS X
10.6–10.8?


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

FYI: updating yasm on build machines

[Chris Peterson]

mozilla-build uses yasm 1.3, but the build machines still use yasm 1.1, 
which is at least three years out of date. Bug 1224408 will update the 
build machines to use yasm 1.3.


There are no expected problems because local builds using mozilla-build 
tools already use 1.3. mozilla-central has yasm code in libvpx, 
spidermonkey, skia, cairo, nss, libjpeg, and webrtc.

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

Re: FYI: updating yasm on build machines

[Chris Peterson]

On 11/20/15 5:09 AM, Neil wrote:

Chris Peterson wrote:


mozilla-build tools already use 1.3


When did it get upgraded? (My mozilla-build only has yasm 1.1)


Last year according to bug 1113450:

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

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

Re: TIFU by using Math.random()

[Chris Peterson]

On 11/25/15 5:51 AM, Xidorn Quan wrote:

According to the article, SpiderMonkey's PRNG is not much better than
V8's. It seems we are using a even older algorithm, although
ironically have a better result.

After reading this article as well as some introduction from the
wikipedia, it seems to me that "xorshift+" is probably the best
algorithm to adopt, because it is simple, fast, and passes all tests
in TestU01 [1], which indicates it should also have a good quality.


We have an implementation of the xorshift128+ PRNG in 
mfbt/XorShift128PlusRNG.h from bug 1206356 that could be used.



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

Re: Dan Stillman's concerns about Extension Signing

[Chris Peterson]

On 11/25/15 11:16 AM, Jeff Gilbert wrote:

I doubt anyone is going to switch to Firefox because our extension
signing is safe. (though I do think we should have some form of
signing) But they will gladly switch away when anything breaks,
particularly when we reduce the activation energy needed to switch: If
their extension won't work in new Firefox, it doesn't matter so much
that they won't have that extension in, say, Chrome.


And that assumes the same extension, or an equivalent, is not available 
for Chrome. Picking a not-so-random example, Zotero has a Chrome extension:


https://chrome.google.com/webstore/detail/zotero-connector/ekhagklcjbdpajgpjgmbionohlpdbjgc
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status: ASan builds on Windows

[Chris Peterson]

On 12/15/15 4:36 PM, Emanuel Hoogeveen wrote:

Not to derail the topic, but I wonder how many crashes would be more actionable 
if they were caught earlier by assertions. I believe Chrome Canary has 
assertions enabled for their testing audience. I don't know how pleasant this 
would be for Nightly users (like myself), since Nightly right now is usually 
pretty stable, but turning MOZ_ASSERT into MOZ_RELEASE_ASSERT (at build time) 
for a select audience would at least be easy to do.


You can selectively enable release asserts in pre-release channels using 
MOZ_DIAGNOSTIC_ASSERT. It's defined as MOZ_RELEASE_ASSERT in Nightly and 
Aurora and debug-only MOZ_ASSERT in Beta and Release.


Instead of blindly enabling possibly-flaky MOZ_ASSERTs in Nightly, we 
could start by converting some important asserts to 
MOZ_DIAGNOSTIC_ASSERT (or even MOZ_RELEASE_ASSERT).


https://mxr.mozilla.org/mozilla-central/ident?i=MOZ_DIAGNOSTIC_ASSERT
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

[Chris Peterson]

On 12/22/15 9:39 AM, Jonathan Griffin wrote:

If we dedicate a cycle to quality and tests, we should use that opportunity
to figure out what a more viable strategy is longer-term for making sure
these don't get out of hand again, which might include having teams adopt
test, suites, and the intermittent orange counts associated with them, and
being accountable for them in goals and deliverables.


The Firefox team plans for three two-week iterations per release cycle. 
To make quality a long-term commitment, we could dedicate the third 
two-week iteration of each release cycle to just fixing tests and bugs.


This has the added benefit of stablizing Nightly before it merges to Dev 
Edition. People have expressed concerns that Dev Edition, as a "real 
product", should have a higher quality bar than Aurora did.


OTOH, a mozilla-central code freeze will frustrate people and lead to 
more big landings in the first or second iteration of the each release 
cycle. That might be OK because those features would then have 2–5 weeks 
of bake time on Nightly instead of just one. :)

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

Re: e10s status update (not going to GA in 45)

[Chris Peterson]

On 12/30/15 12:30 PM, Brad Lassey wrote:

*Population.* Our plan has been to release e10s first to users who have no
add-ons and no a11y features enabled due to known issues with those two
areas of code. Our crash data from the 44 experiment indicates that we have
both sets of users in the experiment population.


What percentage of users are eligible, i.e. have no add-ons and no a11y?

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

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

[Chris Peterson]

On 1/4/16 10:45 AM, Daniel Holbert wrote:

On 01/04/2016 10:33 AM, Josh Matthews wrote:

>Wouldn't the SSL cert failures also prevent submitting the telemetry
>payload to Mozilla's servers?

Hmm... actually, I'll bet the cert errors will prevent Firefox updates,
for that matter! (I'm assuming the update-check is performed over HTTPS.)

So there might be literally nothing we can do to improve the situation
for these users, from a changes-to-Firefox perspective.


On Windows, Firefox is updated by a background service (the Mozilla 
Maintenance Service). Will the SHA-1/spyware proxy breakage affect the 
background service?

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

Re: Does SSE2 usage still need to be conditional?

[Chris Peterson]

On 2/1/16 3:56 PM, Mike Hommey wrote:
> 64-bits Firefox was only officially released recently, and AFAIK, we're not
> offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
> system permits. How about we started doing that?

There are two steps planned to bring 64-bit Firefox to normal release users:

* A "universal" stub installer that downloads 32-bit or 64-bit Firefox,
depending on the user's OS, for new installs.

* Auto-upgrading existing 32-bit users to 64-bit.

This work was planned for 2016, but I don't know the current state.

The primary concerns are NPAPI plugins and add-on compatibility. We only
support Flash and Silverlight on 64-bit Firefox. If a user doesn't have
any other plugins installed, or if they haven't used their other plugins
in N months, perhaps they could be upgraded without problem.


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

Re: rr chaos mode update

[Chris Peterson]

On 2/14/16 9:16 PM, Robert O'Callahan wrote:

Lots of tests have been disabled for intermittency over the years. Now we
have the ability to fix (at least some of) them without much pain, it may
be worth revisiting them, though i don't know how to prioritize that.

We might want to revisit our workflow. If we had the ability to mark tests
as disabled-for-intermittency explicitly, maybe we could automatically
disable intermittent tests as they show up and dedicate a pool of machines
to reproducing them with rr.


While not rr chaos mode, Kats added support to enable Firefox's chaos 
mode for individual reftests. (This was bug 1164218.) Developers should 
consider enabling this option when writing new reftests or fixing issues 
in existing reftests.

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

Re: Talos e10s dashboard

[Chris Peterson]

On 2/26/16 3:58 PM, William Lachance wrote:

I wrote up a dashboard for tracking the performance delta between
non-e10s and e10s on the Talos tests on nightly:

https://treeherder.allizom.org/perf.html#/e10s

(sometime next week, https://treeherder.mozilla.org/perf.html#/e10s
will work too)

Note that the tests are not always measuring exactly the same thing, so
be careful of making naive judgements based on this data (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1250620 for more details).
Still, I thought this might be generally interesting so decided to post
a link to it here.


Will, this dashboard looks great! The current e10s release criteria 
allows regressions up to 5% on the following Talos tests. Is it possible 
to configure your e10s dashboard to display acceptable (<= 5%) 
regressions on these particular tests using another color besides red? 
Perhaps yellow to show that the e10s results are worse than non-e10s, 
but not failure red?


glterrain
sessionrestore
TART
tpaint
tresize
tps
tp5
tp5o
tcanvasmark
tsvgx
tsvgr_opacity


chris

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

Re: Talos e10s dashboard

[Chris Peterson]

On 3/1/16 9:57 AM, William Lachance wrote:

Also, mconley suggested being able to compare the results of individual
subtests. You can access this view for any given talos test by hovering
over the line in the comparison and selecting "subtests". This sometimes
give interesting data, for instance on "tps" some pages are clearly
causing more problems than others:

https://treeherder.allizom.org/perf.html#/e10s_comparesubtest?baseSignature=fe016968d213834efd424ca88680cfa7490b6c09&e10sSignature=5c199ff7bd97284c5f3820ba908f92275620cd8b


(notice how aljaazera.net has a consistent ~450% regression!)


This looks great, Will. Good catch on the aljazeera.net problem. The 
other outliers are mail.ru (at ~410% regression) and guardian.co.uk (at 
~380% regression). We should probably file bugs for those individual 
sites. :)


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

PSA: Introducing MOZ_FALLTHROUGH to annotate intentional switch fallthroughs

[Chris Peterson]

TL;DR?

Annotate intentional switch fallthroughs with `MOZ_FALLTHROUGH;` or 
`MOZ_FALLTHROUGH_ASSERT();` instead of `// fall through` comments.


The details:

clang's -Wimplicit-fallthrough warning (currently off) reports switch 
cases that fall through without a break or return statement. 
MOZ_FALLTHROUGH (bug 1215411) is an annotation macro to suppress the 
warning when the fallthrough is intentional. All -Wimplicit-fallthrough 
warnings in mozilla-central have been fixed and I would like to enable 
-Wimplicit-fallthrough soon (bug 1253170).


We currently have 287 intentional fallthroughs with MOZ_FALLTHROUGH 
annotations. I found 6 unintentional fallthroughs, which is a small 
number but it means 2% of fallthroughs were bugs!


MOZ_FALLTHROUGH is only needed on fallthrough cases that have code:

  switch (foo) {
case 1: // cases without code, so MOZ_FALLTHROUGH is not needed.
case 2:
case 3:
case 4:
  DoSomething(); // case with code, so MOZ_FALLTHROUGH is needed!
  MOZ_FALLTHROUGH;
default:
  return foo;
  }

For clang, MOZ_FALLTHROUGH is #defined as `[[clang::fallthrough]]`, 
which is only available in C++11 code. For MSVC, MOZ_FALLTHROUGH is 
#defined as `__fallthrough`, an annotation checked by MSVC's optional 
"Code Analysis" (/analyze), though I haven't tested this. gcc does not 
have a similar warning or annotation, so MOZ_FALLTHROUGH is a no-op.


Unfortunately, a second annotation macro, MOZ_FALLTHROUGH_ASSERT, is 
needed for switch cases that previously called MOZ_ASSERT(false) to 
assert in debug builds, but intentionally fall through in release builds:


  switch (foo) {
default:
  // This case asserts in debug builds and falls through in release.
  MOZ_FALLTHROUGH_ASSERT("Unexpected foo value?!");
case 5:
  DoSomething();
  }

The problem is that, in release builds, MOZ_ASSERT(false) expands to `do 
{ } while (0)`, requiring a MOZ_FALLTHROUGH annotation to suppress a 
-Wimplicit-fallthrough warning because the case has code. But in debug 
builds, MOZ_ASSERT(false) expands to something like `if (true) { 
MOZ_CRASH(); }`and a MOZ_FALLTHROUGH annotation after MOZ_ASSERT(false) 
will cause an unreachable code warning because the program aborts before 
the fallthrough is reached. The MOZ_FALLTHROUGH_ASSERT macro breaks this 
stalemate. I filed a clang bug suggesting they remove the unreachable 
annotation warning:


https://llvm.org/bugs/show_bug.cgi?id=25966
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Chris Peterson]

On 3/20/16 3:04 AM, Henri Sivonen wrote:

On Sat, Mar 19, 2016 at 2:27 PM,   wrote:

> On Thursday, 17 March 2016 12:23:32 UTC, Henri Sivonen  wrote:

>> (rustc originally bootstrapped with OCaml, but
>> building the whole history of Rust from the OCaml days to present
>> every time Fedora builds Firefox seems excessively impractical.)

>
> Out of interest, would that actually involve building every single Linux 
snapshot from https://github.com/rust-lang/rust/blob/master/src/snapshots.txt in 
sequence? All 319 of them?

Presumably, yes, if you want to bootstrap from OCaml. Maybe you could
skip some snapshots, but you don't know which ones in advance.
Fortunately, e.g. the Fedora policy doesn't require bootstrapping all
the way from OCaml.


How does Debian bootstrap other compilers like Go that are partially 
self-hosted? Would a Rust compiler written in C/C++ (e.g. generated by 
an LLVM back-end that emitted C/C++ code?) avoid the bootstrap policy 
requirements?

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

Re: Skia Content on OS X

[Chris Peterson]

On 3/22/16 9:03 AM, Mason Chang wrote:

It’s also quite nice that micro-level optimizations at the backend level can 
mostly be done for us as Skia is optimizing performance with Chrome as one of 
their use cases.


On which platforms does Chrome use Skia?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Chris Peterson]

On 3/24/16 10:13 AM, atu...@mozilla.com wrote:

The Rust core team met yesterday and developed a complete plan for Rust to be 
build with the previous stable compiler as snapshot. We will be landing the 
infrastructure needed to do this shortly.

In terms of release timing, it will take some time for this change to fully 
propagate. Our most recent Rust snapshot happened after the 1.8 beta, leading 
to the following picture:

- Rust 1.8 -- already in beta; hits stable on Apr 14th
- Ad hoc snapshot
- Rust 1.9 -- builds from ad hoc snapshot
- Rust 1.10 -- builds from Rust 1.9 stable

The Rust 1.10 stable release will happen about 15 weeks from now, and under 
this plan will be the first release to bootstrap this way.


Aaron, so going forward, Rust version N should always be buildable by 
version N-1 (starting with N = 1.10)?

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

Re: Intent to switch to Visual Studio 2015

[Chris Peterson]

On 3/24/16 9:44 AM, Gregory Szorc wrote:

Inbound is now building with VS2015!


Chromium switched to VS2015 in March 2016. The following blog post 
details some of the compiler bugs Google found. It might be worth 
reviewing them in case Firefox runs into any of them.


https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Chris Peterson]

On 3/31/16 3:22 PM, Daniel Veditz wrote:

​We get that now, with no marker at all. The only real difference I see
with a marker is that people will catch on sooner whereas now it takes a
while until they realize they are being ignored. They eventually get
discouraged​ or upset either way. Might even be better with a marker (for
some people) because at least they have some acknowledgement that someone
has looked at the bug even if they disagree about the importance. We may
have misunderstood, and thus mis-triaged, the bug and an explicit marker
might trigger the attempt to clarify sooner.


Anthony's Media Playback team has been using a simple and effective 
triage system without special tags. All open bugs in the Audio/Video 
Playback component are in one of four states at all times:


* Priority P1 bugs should be fixed ASAP.
* Priority P2 bugs are real bugs or features we want to fix soon.
* Priority P5 bugs are "patches accepted" bugs.
* Bugs without a priority are untriaged.

P3 and P4 are not used. :) P5 sends a pretty clear message to people 
that we will not fix that issue any time soon. However, the P5 list is 
pretty clean because we aggressively WONTFIX bugs we truly don't want to 
fix instead of letting them linger.


Bugzilla already has a lot of fields. It seems like new workflows could 
be built with a streamlined frontend UI without changing Bugzilla's 
database schema. The advantage of codifying existing workflows instead 
of adding new fields is that existing bugs will be compatible with the 
new system.


IIRC, the Fennec team also tracked the "Someone is working on this" 
proposed in Emma's plan by assigning owners to all bugs, but developers 
would change their bug's status from NEW to ASSIGNED only when they 
began actively working on the bug.

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

Re: Triage Plan for Firefox Components

[Chris Peterson]

On 4/1/16 10:57 AM, Emma Humphries wrote:

Could you add how your team maps the the priority flag, or link to a page
describing it?

https://wiki.mozilla.org/index.php?title=Bugmasters/Projects/Folk_Knowledge/Priority_Field&action=edit&redlink=1


This is interesting information! Do you have other "folk knowledge" from 
teams using Bugzilla? It may be useful to interview a number of 
engineers and managers about their teams' current Bugzilla workflows. 
And perhaps an etherpad for a big brain dump and bikeshedding. :)


If we can "pave some cowpaths" by standardizing proven patterns using 
our existing tools, there may be less resistance or bikeshedding to new 
proposals.


For example, here are some existing fields that different teams use 
(inconsistently) to prioritize future work:


- Priority
- Severity
- Rank (1–60)
- Votes
- Target Milestone
- Iteration
- custom tracking flags like tracking-e10s, firefox‑backlog, blocking-fx
- custom 'project flags' for B2G
- custom whiteboard tags
- various 'wanted' and priority keywords
- meta bugs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style for C++ enums

[Chris Peterson]

On 4/8/16 8:10 AM, Kartikaya Gupta wrote:

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


FWIW, Google's C++ Style Guide dictates that enums in new code use 
kPrefixedNames. SHOUTY_CAPS are allowed in older code.


https://google.github.io/styleguide/cppguide.html#Enumerator_Names
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Chris Peterson]

I've long thought that Bugzilla should be more like Wikipedia: the 
"front page" of the bug is editable and always up-to-date (i.e. not 
incorrect or outdated STRs), but the history and meta discussion is 
still available on a "back page".



On 4/12/16 2:19 PM, David Lawrence wrote:

I used to think it should be called "Abstract". Sort of a summarization
of the bug itself.

dkl

On 04/12/2016 05:02 PM, Emma Humphries wrote:

This is probably a field that could stand to be re-labled, as I was
blithely thinking (and I would guess others are) that it was for features,
only.

-- Emma

On Tue, Apr 12, 2016 at 1:01 PM, Mark Côté  wrote:


On 2016-04-07 2:50 AM, L. David Baron wrote:

(I'd much rather a bug report be editable text, with history
available, for answers to these or similar questions -- rather than
a stream of permanent comments.  But we seem stuck with the horrid
stream-of-comments Bugzilla format, which means I try to ignore the
comments as much as I can.  Then again, a 200 character summary is
often good enough to answer the above 5 questions.  As with the rest
of the Internet, don't read the comments.)


Meant to reply to this earlier... BMO has a User Story field that sounds
like it does exactly what you want.  It's an editable field that keeps
history (admittedly not in an easy-to-read way, but that could be
improved).  Despite the name of the field, I've found it useful for
summarizing the current state of the discussion in the bug (sometimes
along with the "obsolete" comment tag).

Mark

___
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

Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

Summary: Treat cookies set over non-secure HTTP as session cookies

Exactly one year ago today (!), Henri Sivonen proposed [1] treating 
cookies without the `secure` flag as session cookies.


PROS:

* Security: login cookies set over non-secure HTTP can be sniffed and 
replayed. Clearing those cookies at the end of the browser session would 
force the user to log in again next time, reducing the window of 
opportunity for an attacker to replay the login cookie. To avoid this, 
login-requiring sites should use HTTPS for at least their login page 
that set the login cookie.


* Privacy: most ad networks still use non-secure HTTP. Content sites 
that use these ad networks are prevented from deploying HTTPS themselves 
because of HTTP/HTTPS mixed content breakage. Clearing user-tracking 
cookies set over non-secure HTTP at the end of every browser session 
would be a strong motivator for ad networks to upgrade to HTTPS, which 
would unblock content sites' HTTPS rollouts.


However, my testing of Henri's original proposal shows that too few 
sites set the `secure` cookie flag for this to be practical. Even sites 
that primarily use HTTPS, like google.com, omit the `secure` flag for 
many cookies set over HTTPS.


Instead, I propose treating all cookies set over non-secure HTTP as 
session cookies, regardless of whether they have the `secure` flag. 
Cookies set over HTTPS would be treated as "secure so far" and allowed 
to persist beyond the current browser session. This approach could be 
tightened so any "secure so far" cookies later sent over non-secure HTTP 
could be downgraded to session cookies. Note that Firefox's session 
restore will persist "session" cookies between browser restarts for the 
tabs that had been open. (This is "eternal session" feature/bug 530594.)


To test my proposal, I loaded the home pages of the Alexa Top 25 News 
sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set 
over HTTPS and only 7 had the `secure` flag. About 900 were third-party 
cookies. Treating non-secure cookies as session cookies means that over 
1100 cookies would be cleared at the end of the browser session!


CONS:

* Sites that allow users to configure preferences without logging into 
an account would forget the users' preferences if they are not using 
HTTPS. For example, companies that have regional sites would forget the 
user's selected region at the end of the browser session.


* Ad networks' opt-out cookies (for what they're worth) set over 
non-secure HTTP would be forgotten at the end of the browser session.


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

Link to standard: N/A

Platform coverage: All platforms

Estimated or target release: Firefox 49

Preference behind which this will be implemented: 
network.cookie.lifetime.httpSessionOnly


Do other browser engines implement this? No

[1] 
https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ

[2] http://www.alexa.com/topsites/category/Top/News
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

Thanks for all the feedbck. I anticipated this proposal might not be 
practical with real world sites, so it's better to halt it here. :) I 
should have framed this email as an RFC instead of an intent to ship.


Focusing on third-party session cookies is an interesting idea. 
"Sessionizing" non-HTTPS third-party cookies would encourage ad networks 
and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed 
content problems. Much later, we could consider sessionizing even HTTPS 
third-party cookies.


I'll think about telemetry probes that could be added to better 
understand these scenarios. I'm surprised we don't have much telemetry 
about cookie usage. Monica Chew wrote [1] about a Mozilla study of 
cookies, but that was only 573 users back in 2013.



chris

[1] http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html


On 4/14/16 1:54 AM, Chris Peterson wrote:

Summary: Treat cookies set over non-secure HTTP as session cookies

Exactly one year ago today (!), Henri Sivonen proposed [1] treating
cookies without the `secure` flag as session cookies.

PROS:

* Security: login cookies set over non-secure HTTP can be sniffed and
replayed. Clearing those cookies at the end of the browser session would
force the user to log in again next time, reducing the window of
opportunity for an attacker to replay the login cookie. To avoid this,
login-requiring sites should use HTTPS for at least their login page
that set the login cookie.

* Privacy: most ad networks still use non-secure HTTP. Content sites
that use these ad networks are prevented from deploying HTTPS themselves
because of HTTP/HTTPS mixed content breakage. Clearing user-tracking
cookies set over non-secure HTTP at the end of every browser session
would be a strong motivator for ad networks to upgrade to HTTPS, which
would unblock content sites' HTTPS rollouts.

However, my testing of Henri's original proposal shows that too few
sites set the `secure` cookie flag for this to be practical. Even sites
that primarily use HTTPS, like google.com, omit the `secure` flag for
many cookies set over HTTPS.

Instead, I propose treating all cookies set over non-secure HTTP as
session cookies, regardless of whether they have the `secure` flag.
Cookies set over HTTPS would be treated as "secure so far" and allowed
to persist beyond the current browser session. This approach could be
tightened so any "secure so far" cookies later sent over non-secure HTTP
could be downgraded to session cookies. Note that Firefox's session
restore will persist "session" cookies between browser restarts for the
tabs that had been open. (This is "eternal session" feature/bug 530594.)

To test my proposal, I loaded the home pages of the Alexa Top 25 News
sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
over HTTPS and only 7 had the `secure` flag. About 900 were third-party
cookies. Treating non-secure cookies as session cookies means that over
1100 cookies would be cleared at the end of the browser session!

CONS:

* Sites that allow users to configure preferences without logging into
an account would forget the users' preferences if they are not using
HTTPS. For example, companies that have regional sites would forget the
user's selected region at the end of the browser session.

* Ad networks' opt-out cookies (for what they're worth) set over
non-secure HTTP would be forgotten at the end of the browser session.

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

Link to standard: N/A

Platform coverage: All platforms

Estimated or target release: Firefox 49

Preference behind which this will be implemented:
network.cookie.lifetime.httpSessionOnly

Do other browser engines implement this? No

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ

[2] http://www.alexa.com/topsites/category/Top/News


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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/15/16 7:47 AM, Tantek Çelik wrote:

What steps can we take in this direction WITHOUT breaking web compat?


Would this feature actually break web compatibility? Or just needlessly 
annoy users?


In his original post, Henri argued that clearing non-HTTPS cookies 
between sessions would not "Break the Web". There would be no user- or 
site-detectable changes mid-session. Clearing cookies between sessions 
could be user-detectable if they get logged out or lose their shopping 
cart. Sites, OTOH, must already handle the cases were a user's cookies 
are lost between sessions. Users could clear their cookies, use Private 
Browsing mode, or log into the site from a different browser or device.



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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/15/16 2:12 AM, Jason Duell wrote:

> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could consider sessionizing even HTTPS
> third-party cookies.
>

How about we sessionize only 3rd party HTTP cookies from sites that are on
our tracking protection list?  That seems the most targeted way to
encourage ad networks to bump up to HTTPS with a minimal amount of
collateral damage to other users of 3rd party HTTP cookies.


The IAB recently announced a "LEAN Ads" initiative [1]: Light, Encrypted 
(HTTPS), Ad Choice supported, and Non-invasive.


When the IAB agrees ad networks should use HTTPS, clearing HTTP cookies 
from third parties and/or sites on the Tracking Protection list becomes 
an easier sell, policy-wise. We're not talking about blocking cookies or 
content, just reducing the cookie lifetime.



[1] http://www.iab.com/news/lean/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving XP to ESR?

[Chris Peterson]

On 4/18/16 6:46 AM, Thomas Zimmermann wrote:

Am 18.04.2016 um 15:18 schrieb Kyle Huey:

> 12% of our users are on Windows XP.

And XP still runs on ~10% of all desktops. That's an opportunity to
convert some of the users to Firefox.


If we want to convert some Chrome XP users, we could run a small social 
media promotion to inform them that Firefox still supports XP. 
Otherwise, how would they know?


OTOH, if an XP users doesn't mind running an unpatched OS, then they 
probably won't care/know about running an unpatched Chrome browser.

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

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/19/16 1:58 AM, Panos Astithas wrote:

Why should we be the ones to take the web compat hit on this?

>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for.


The challenge is that users experience broken websites (web compat) 
firsthand, but privacy and security are invisible.

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

Re: Proposal: use nsresult& outparams in constructors to represent failure

[Chris Peterson]

On 4/20/16 11:43 PM, Gerald Squelart wrote:

How about another generic helper, e.g.:
  template 
  Maybe MakeCheckedMaybe(Args&&... aArgs)
  {
nsresult rv;
Maybe m = Some(T(std::forward(aArgs)..., &rv));
if (NS_SUCCEEDED(rv)) {
  return m;
}
return Nothing();
  }


Existing classes with Init() member functions could be shoehorned, 
unchanged, into this pattern with a MakeUnique() variant that called and 
checked Init(). Something like:


MakeUniqueAndInit(Args&&... aArgs)
{
  UniquePtr up(new T(Forward(aArgs)...));
  return NS_SUCCEEDED(up.Init()) ? up : UniquePtr();
}


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

Re: Intent to ship: Restrict geolocation.watchPosition to secure contexts

[Chris Peterson]

On 4/21/16 11:00 AM, Richard Barnes wrote:

This is clearly a powerful feature, so it's a natural candidate for
restriction.  Chromium is restricting all of navigator.geolocation as of 50:

https://codereview.chromium.org/1530403002/


Just to be clear, Firefox will still allow getCurrentPosition() in 
non-secure contexts?



Our telemetry shows that only ~0.1% of the usage of watchPosition() is in
non-secure contexts.

http://mzl.la/1VEBbZq

That's low enough that we should go ahead and turn it off.


Curiously, getCurrentPosition() is called in non-secure contexts 77% of 
the time, compared to watchPosition()'s 0.12%.


I would have assumed that getCurrentPosition() is used much more often 
than watchPosition(), as most map sites only need a one-shot location. 
However, telemetry shows getCurrentPosition() has sample count 10M with 
metric count ~1M compared to watchPosition() has sample count 39M and 
metric count 488K. Why the disparity? Why does watchPosition() have 4x 
sample count but only half the metric count? I wondered whether 
watchPosition() was incorrectly recording telemetry on every watch 
callback, but the code looks like it is doing the right thing.

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

Re: MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

[Chris Peterson]

On 4/29/16 5:53 AM, Nathan Froyd wrote:

This is a noble goal, but there is an enormous amount of code that
would need to be modified to make this feasible.  Perhaps if you
exempted nsresult from MOZ_MUST_USE types.


In theory, nsresult seems like an important type to check.

That said, I once tried building Gecko with `#define NS_IMETHOD 
MOZ_WARN_UNUSED_RESULT NS_IMETHOD_(nsresult)`. There were over 10,000 
warnings for XPCOM method callers not checking nsresult return values, 
so this approach does not seem practical. :(

___
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

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 
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/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