Re: Studying Lossy Image Compression Efficiency

[chris]

On Thursday, October 17, 2013 1:50:12 PM UTC-4, cry...@free.fr wrote:
> Thank you for publishing this study, here are my first questions:
> 
> - Why didn't you include JPEG 2000?

You might find https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120 
interesting: it discusses what it would take to get a new format into Firefox: 
a high-quality open-source library, some level of security vetting and a solid 
rights statement.

I think JP2 support could potentially be very interesting because it would make 
responsive images almost trivial without requiring separate files (i.e. srcset 
could simply specify a byte-range for each size image) but the toolchain 
support needs some serious attention.

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

Re: Removal of native notification systems on desktop platforms

[chris]

On Monday, October 28, 2013 6:38:07 AM UTC-5, Philip Chee wrote:
> On 28/10/2013 16:02, Florian Bender [:fbender] wrote:
> 
> > Mac OS X Mavericks has been released with improvements to NC. Safari
> 
> > uses NC to display Web/PushNotifications and seems to work quite
> 
> > well.
> 
> > 
> 
> > I'd like you to revisit the decision to drop NC in favor of XUL
> 
> > Notifications, and have a second look at the new API and
> 
> 
> 
> Nitpick. NC wasn't dropped. We never supported the OS X NC at all. There
> 
> was some preliminary work but that was never checked-in to mozilla-central.
> 
> 
> 
> > capabilities. NC support could be limited to 10.9 to reduce
> 
> > maintenance cost (luckily, nearly everyone is eligible for the free
> 
> > update which means that earlier versions could fade into irrelevance
> 
> > sooner than later), and keep the XUL Notifications for 10.6-10.8 (as
> 
> > long as these versions are supported and have a meaningful market
> 
> > share).
> 
> 
> 
> I believe that this is one of those "patches welcome" occasions.
> 
> 

This is what I do not understand. If the Growl framework had simply been 
updated instead of removed, then you would have been able to support 10.6 -> 
10.9 without any more maintenance than updating the framework.

There are references to why the framework was removed, but nothing specific. 
Now I have end users coming to us confused as to why Firefox and plugins for 
FF, along with Thunderbird are all not notifying through Growl. Which is really 
frustrating because I cannot for the life of me figure out from all of the 
tickets why exactly Growl support was removed.

I asked on a bug but apparently that was the wrong place to ask, so I'll ask on 
this thread which was linked. I'll copy what i wrote over there:

I would also like to find out why Growl was removed. We're getting user 
complaints because users don't understand why their firefox plugins are not 
notifying through Growl anymore. I'd like to explain it better than "because 
someone at Mozilla arbitrarily decided to remove it instead of talking to us 
about what features they needed". Which so far is exactly how it looks.

I just need a simple 1-3 sentence explanation that I can send to my end users 
as to why a feature they depended upon is no longer present. I would also like 
a much more technical explanation as to why Growl support was removed because 
obviously we'd like to address those kinds of issues going forward.

What I do not understand is that the feature for this was developed in our 
repository. The framework was paired down to work with the very stringent 
requirements that Mozilla has in order to get Growl support to work. The 
framework we provide now supports native notifications on 10.8 and 10.9. On 
10.6 and 10.7 there are no native notifications so Growl is the only game in 
town, but you do not need Growl in your application, just the framework, in 
order to fire a notification to the end user.

We could have made the adjustments to our notification framework to give not 
only Mozilla what they wanted, but also provide those changes to the entire mac 
community that uses our framework. So if someone explains exactly what the 
problem is, we'd be happy to look at addressing those things.

Hopefully you can see why this is frustrating to me, and more importantly to 
our mutual end users who are the ones who are affected by this (currently) 
seemingly arbitrary change.


Chris Forsythe
Project Lead - The Growl Project
ch...@growl.info

> 
> Phil
> 
> -- 
> 
> Philip Chee , 
> 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> 
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> 
> oh Night, and so be good for us to pass.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: WOFF2 webfont format

[chris]

On Friday, 3 October 2014 02:12:22 UTC+2, Jonas Sicking  wrote:

> Could we at least add woff2 to the Accept header when fetching fonts?

If Internet Media Types for fonts were widely and consistently deployed, then 
that sort of server-mediated content negotiation (client sends list of accepted 
formats and q factors, sever decides what is best and sends it) would probably 
work.

However, they are not and never have been; also early attempts to creat a 
font/* top level type were blocked. Which is why @font-face uses a format hint 
instead. This is client-mediated content negotiation (content provides list of 
avbailable formats and a link to each, client decides what is best and asks for 
it).

This works well in practice. Thus, an ordered list of urls and formats in a scr 
descriptor remains the recommended deployment method; it needs no web server 
config changes and no ua detection, and is resilient to fonts in the wild being 
served as text/plain or application/octet-stream or whatever the sever defaults 
to for "no idea what this is".

Which is not to argue against sending sensible accept headers, but cleaning 
that up is orthogonal to woff2 deployment.

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

Re: A reminder about MOZ_MUST_USE and [must_use]

[Chris Peterson]

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

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


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

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


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

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

Re: Intent to implement and ship: 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: All the processes

[Chris Pearce]

We also have the Gecko Media Plugin process type. It's not the same as Flash 
plugin process. There are at least one per origin doing EME and one shared by 
all users of WebRTC that need to encode/decode H.264.

The media playback team are also working on moving the code that interacts with 
the platforms' audio subsystem into its own process, but that project has only 
recently started.

cpearce.



On Saturday, March 4, 2017 at 1:16:00 PM UTC+13, Nicholas Nethercote wrote:
> Hi,
> 
> I want to understand all the different processes that we can and will have
> in Firefox. Here's a list I constructed off the top of my head.
> 
> - main process
> 
> - content process(es): 1 on release for most users; 2 on Nightly
> 
> - plugin process: just for Flash now?
> 
> - gfx compositor process (bug 1264543, in Fx53)
> 
> - file:// URL access process (bug 1147911, in Fx53)
> 
> IIRC there was a proposal for a thumbnail generation process a while back
> but judging by bug 1187441 that was scrapped.
> 
> Do I have any of these details wrong? Have I missed any?
> 
> Thanks.
> 
> Nick

___
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: Project Stockwell (reducing intermittents) - March 2017 update

[Chris Pearce]

I recommend that instead of classifying intermittents as tests which fail > 30 
times per week, to instead classify tests that fail more than some threshold 
percent as intermittent. Otherwise on a week with lots of checkins, a test 
which isn't actually a problem could clear the threshold and cause unnecessary 
work for orange triage people and developers alike.

The currently published threshold is 8%:

https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy#Identifying_problematic_tests

8% seems reasonable to me.

Also, whenever a test is disabled, not only should a bug be filed, but please 
_please_ need-info the test owner or at least someone on the affected team.

If a test for a feature is disabled without the maintainer of that feature 
knowing, then we are flying blind and we are putting the quality of our product 
at risk.


cpearce.



On Wednesday, March 8, 2017 at 9:06:46 AM UTC+13, jma...@mozilla.com wrote:
> On Tuesday, March 7, 2017 at 2:57:21 PM UTC-5, Steve Fink wrote:
> > On 03/07/2017 11:34 AM, Joel Maher wrote:
> > > Good suggestion here- I have seen so many cases where a simple
> > > fix/disabled/unknown/needswork just do not describe it.  Let me work on a
> > > few new tags given that we have 248 bugs to date.
> > >
> > > I am thinking maybe [stockwell turnedoff] - where the job is turned off- 
> > > we
> > > could also ensure one of the last comments indicates this.
> > >
> > > also [stockwell fix] -> [stockwell testfix], [stockwell bandaid] (for 
> > > those
> > > requestLongerTimeouts(), etc.), [stockwell productfix], and [stockwell
> > > reneabled].
> > 
> > Forgive the bikeshedding, but my kneejerk reaction to these is to wonder 
> > whether it's a good idea to use the "stockwell" jargon. It would be a 
> > lot easier for people unfamiliar with the stockwell project if these 
> > were [intermittent turnedoff], [intermittent fix], etc. Perhaps it's too 
> > late, but is that a possibility?
> 
> I think that is valid, thanks for bringing that up!

___
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: e10s-multi update and tests

[Chris Pearce]

On Thursday, March 23, 2017 at 2:37:18 PM UTC+13, Nicholas Nethercote wrote:
> On Thu, Mar 23, 2017 at 12:12 PM, Andrew McCreight
> wrote:
> 
> >
> > Though maybe you are asking which processes count against the limit of 4.
> >
> 
> Yes, that's what I am asking.
> 
> Nick

I think there's only one GPU process active at once.

GMP processes are not a content process, and should not count towards the 
content process limit.

At this stage I don't think we need to put a limit on how many GMP processes 
are active at once. All WebRTC's use of GMP shares a single GMP process. We do 
create a new GMP process for every origin doing EME, but in typical usage 
patterns I'd not expect many origins using EME concurrently. GMP processes also 
typically don't use more than 10MB of memory. So I don't think GMP processes 
will be an issue.

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

Re: Intent to implement and ship: support ::cue pseudo-element from document.

[Chris Pearce]

On Wednesday, March 29, 2017 at 11:21:06 PM UTC+13, bec...@mozilla.com wrote:
> Summary:
> We are going to support ::cue(with no argument) pseudo-element for webvtt.
> It allows styling the webvtt subtitle/caption text during video playback.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1318542
> 
> Spec: https://w3c.github.io/webvtt/#the-cue-pseudo-element
> 
> Platform coverage:
> All platforms
> 
> Estimated or target release:
> Firefox 55
> 
> Preference:
> media.webvtt.pseudo.enabled, default is true.
> 
> DevTools bug:
> None.
> 
> Do other browser engines implement this?
> Yes, chrome, safari, opera
> 
> Web Developer Use-Cases:
> write the ::cue style block in the document, then ::cue rules will be applied 
> to the .vtt subtitle. Note that the ::cue style block can only appear in 
> document, not in vtt file (not support yet).
> 
> ::cue {
>   ...
> }
> 
> 
>  
> 
> 
> Tests:
> web-platform/tests/webvtt/rendering/cues-with-video/processing-model/selectors/*
> Tests under the folder are disabled now, I'm going to enable/fix them.

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

Re: Rationalising Linux audio backend support

[Chris Coulson]

On 31/03/17 05:52, burmar...@gmail.com wrote:
> Ubuntu just re-enabled ALSA on their latest Firefox 52.0.2 release. Go Ubuntu!
It's enabled, but please see the small-print in the changelog
description at
https://launchpad.net/ubuntu/+source/firefox/52.0.2+build1-0ubuntu0.16.04.1.
The Firefox package in Ubuntu is maintained by 1 contributor in his
spare time and myself who is only able to do the minimum in order to
provide updates, so Ubuntu flavors that don't ship Pulseaudio need to
step up to maintain this code if they want it to continue working and
don't want it to be disabled again in a future update.

Regards
- Chris
> So thankfully I and many others can now forget about this sorry business.
>
> Martin Burke
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform




signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rationalising Linux audio backend support

[Chris Coulson]

On 05/04/17 19:38, Henri Sivonen wrote:
> On Mar 31, 2017 4:49 PM, "Chris Coulson" 
> wrote:
>
> The Firefox package in Ubuntu is maintained by 1 contributor in his
> spare time and myself who is only able to do the minimum in order to
> provide updates,
>
>
> Does today’s announcement of Ubuntu’s change in direction affect resourcing
> for Firefox packaging?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
I don't have the answer to that right now.

- Chris



signature.asc
Description: OpenPGP digital signature
___
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: Tier 3 win64 ASan builds on try

[Chris Pearce]

On Friday, April 7, 2017 at 2:11:32 PM UTC+12, Ting-Yu Chou wrote:
> Just a heads up that now we have win64 ASan builds on try. The try format:
> 
>   try: -b o -p win64-asan -u none -t none
> 
> Bug 1347793 is tracking the failed tests on taskcluster, though by now the
> tests
> for normal windows builds are not all green yet and I haven't seen any real
> ASan
> issue.
> 
> I am not sure if js/fuzzing folks are interested, but probably we can try
> to do
> fuzzing for jsshell-asan, on windows. (Wonder do we have automated fuzzing
> tests
> on any infrastructure.)
> 
> Note this is still in tier 3, things can regress easily.
> 
> Ting

Awesome!

Is there a wiki page detailing how to setup a Win64 ASAN build locally?
___
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

Reminder - TCW tomorrow May 6th from 0500-1200 PT

[Chris AtLee]

As indicated on our status page:
https://status.mozilla.org/incidents/cpnkqqb6b5kh

We will be closing trees tomorrow from 0500-1200PT.

Tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1355897

Thank you for your patience
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Notification() deprecation question

[Chris Mills]

Hi there,

I found this thread recently:

https://bugs.chromium.org/p/chromium/issues/detail?id=481856

Are we following the same path to deprecating Notification() and insisting 
people use ServiceWorkerRegistration.showNotification() instead in Gecko, or is 
this just a Google thing for now? 

In any case, we’ve got some documentation updates to do on MDN — I just wanted 
to check exactly what the deal is.

Thanks,

Chris Mills
 MDN content lead || Mozilla
developer.mozilla.org || MDN
   cmi...@mozilla.com || @chrisdavidmills

___
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

Nightly updates disabled for bug 1364059

[Chris AtLee]

We've disabled updates for a bad crash:
https://bugzilla.mozilla.org/show_bug.cgi?id=1364059

We're working on backing out the offending patches and will re-spin nightly
builds shortly.

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

Re: Nightly updates disabled for bug 1364059

[Chris AtLee]

Updates are enabled again for all platforms. Not all locales have finished
yet, they will receive updates once the repacks finish.

On 11 May 2017 at 09:30, Chris AtLee  wrote:

> We've disabled updates for a bad crash: https://bugzilla.mozilla.org/
> show_bug.cgi?id=1364059
>
> We're working on backing out the offending patches and will re-spin
> nightly builds shortly.
>
> Cheers,
> Chris
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: Insecure use of Encrypted Media Extensions

[Chris Pearce]

Summary: The EME spec [1] states that EME should only be usable from a secure 
origin (i.e. on a domain being served over HTTPS). Currently Gecko's 
implementation works on insecure origins (i.e. sites served over unencrypted 
HTTP). To bring our implementation in line with the spec, we're going to remove 
support for EME on non-secure origins.

Sites using EME that are not using secure origins should switch to HTTPS as 
soon as possible.

Chrome has just removed support for insecure EME in Chrome 58, their most 
recent release.

Motivation: EME makes use of proprietary CDMs that have access to persistent 
storage and that may transmit identifiers to DRM license servers. Requiring 
secure origin and transport makes it harder for the CDM to be attacked by 
others on the channel.

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

Standard: https://www.w3.org/TR/encrypted-media/

Platform coverage: This will affect everywhere that we support EME; Windows, 
MacOS, Linux, Android.

Estimated target date: TBD. Hopefully we can ship this by the end of 2017.

Our telemetry [2] indicates that about 18% of EME use is still on insecure 
origins. We're shipping a deprecation warning in the WebConsole in Firefox 55, 
and given that Chrome have removed this in their latest release I expect we 
should see migration of sites using EME to HTTPS. Once our telemetry indicates 
that use of EME on insecure origins is sufficiently rare, we will go ahead and 
remove support for EME on insecure origins.


[1] https://www.w3.org/TR/encrypted-media/#privacy-secureorigin
[2] https://mzl.la/2rs9maH
___
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: Start logging at runtime (Firefox 52)

[Chris Pearce]

On Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> Hi everyone,
> 
> (I meant to send this mail a few weeks ago but forgot it in my Drafts
> folder.)
> 
> With the landing of Bug 1303762 (Firefox 52), we now have a way for users
> to enable logging without restarting the browser, and without having to
> know what an environment variable is.
> 
> We've added a new Logging section to about:networking. When a user
> encounters a bug, all they have to do is open that page, click on "Start
> Logging", reproduce the bug, then click on "Stop Logging" and upload the
> logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> variables have been defined.
> The log modules are automatically set to the most common networking
> modules, but you may instruct the bug reporters to change them - just tell
> them the string.
> 
> This is very useful for bugs that are harder to reproduce once you restart
> the browser.
> 
> There are a bunch of improvements that we could make to the UI, so please
> feel free to send me your feedback and patches. Many thanks to Honza
> Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that helped
> with the implementation and review of this bug and its dependencies.
> 
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging?document_saved=true#Using_aboutnetworking

This seems super handy, but I tried it out and it seems to only affect the 
parent process, and not the sub-processes of Firefox?

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

Re: Start logging at runtime (Firefox 52)

[Chris Pearce]

On Wednesday, May 24, 2017 at 2:22:49 AM UTC+12, Valentin Gosu wrote:
> I think the you can get around the issue by setting the
> security.sandbox.content.level pref to 0 while you're debugging.
> 
> On 23 May 2017 at 08:32, Shih-Chiang Chien  wrote:
> 
> > Which platform you're using? For windows it seems to be solved by
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1320458, however other
> > platforms are not fixed yet.
> >
> >
> > Best Regards,
> > Shih-Chiang Chien
> > Mozilla Taiwan
> >
> > On Tue, May 23, 2017 at 11:59 AM, Chris Pearce 
> > wrote:
> >
> > > On Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> > > > Hi everyone,
> > > >
> > > > (I meant to send this mail a few weeks ago but forgot it in my Drafts
> > > > folder.)
> > > >
> > > > With the landing of Bug 1303762 (Firefox 52), we now have a way for
> > users
> > > > to enable logging without restarting the browser, and without having to
> > > > know what an environment variable is.
> > > >
> > > > We've added a new Logging section to about:networking. When a user
> > > > encounters a bug, all they have to do is open that page, click on
> > "Start
> > > > Logging", reproduce the bug, then click on "Stop Logging" and upload
> > the
> > > > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> > > > variables have been defined.
> > > > The log modules are automatically set to the most common networking
> > > > modules, but you may instruct the bug reporters to change them - just
> > > tell
> > > > them the string.
> > > >
> > > > This is very useful for bugs that are harder to reproduce once you
> > > restart
> > > > the browser.
> > > >
> > > > There are a bunch of improvements that we could make to the UI, so
> > please
> > > > feel free to send me your feedback and patches. Many thanks to Honza
> > > > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that
> > helped
> > > > with the implementation and review of this bug and its dependencies.
> > > >
> > > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> > > HTTP_logging?document_saved=true#Using_aboutnetworking
> > >
> > > This seems super handy, but I tried it out and it seems to only affect
> > the
> > > parent process, and not the sub-processes of Firefox?
> > >
> > > ___
> > > 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
> >

I'm using Firefox 54b10 32bit on Windows 10 x64.

Changing the sandbox pref worked, though it required a restart.

Has anyone thought of routing MOZ_LOGs to the Browser Console? How hard would 
that be?
___
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

Profiling nightlies on Mac - what tools are used?

[Chris Cooper]

Hey all,

The build peers are looking to change the way that nightlies are created on Mac 
as we switch to cross-compilation. Specifically, we're looking at stripping the 
nightlies to avoid an as-of-yet undiagnosed performance discrepancy vs native 
builds[1], but also to make the nightly configuration match what we ship on 
beta/release (stripped).

Of course, stripping removes the symbols, and while we believe we have a 
solution for re-acquiring symbols that works for the Gecko Profiler, we realize
that people out there may be using other profiling tools.

If you profile on Mac, now is your chance to speak up. What other profiling 
tools do you use that we should be aware of?

cheers,
--
coop

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1338651
___
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 Cooper]

On Tuesday, June 20, 2017 at 1:28:50 PM UTC-4, Ehsan Akhgari wrote:
> > My understanding is that the slowdown cannot be reproduced on local
> > developer machines, but can be reproduced on loaner machines from
> > infra.
> Huh.  That's interesting and even more puzzling...
> > I don't think anybody has tried profiling on infra to see
> > where time differences are.
> 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...

One possible avenue we're considering is shipping the unstripped cross-compiled 
builds to the nightly audience (or some subset) and seeing if the performance 
issue manifests in the wild. We're confident in our ability to repatriate these 
users via nightly updates.
___
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: [Sheriffs] switch to macosx cross-compiled builds on taskcluster on trunk

[Chris Cooper]

\o/

This was a multi-year project, and I'm ecstatic to see it finally come
to fruition. Thanks to everyone who's been involved in getting this
across the line.

cheers,
--
coop

On Thu, Jun 22, 2017 at 3:09 PM, Kim Moir  wrote:
> After successful testing this morning, we have now enabled macosx nightly
> updates again.
>
> The migration is complete, enjoy your cross compiled builds and more
> scalable CI infrastructure.
>
> Kim
>
> On Wed, Jun 21, 2017 at 10:04 PM, Kim Moir  wrote:
>>
>> Status update:
>>
>> We have successful cross compiled macosx opt builds running on trunk.  We
>> also have run a successful nightly cross compiled nightly on m-c.  We are
>> going to leave the rule in place that blocks updates for macosx nightlies so
>> we can test and update from tonight's nightly to tomorrow's nightly on the
>> test channel, before enabling updates for all nightly users.
>>
>> Kim
>>
>> On Wed, Jun 21, 2017 at 12:35 PM, Kim Moir  wrote:
>>>
>>> At 11:00PT today, we will be landing patches to run mac opt builds on
>>> trunk as cross compiled builds on Linux machines on taskcluster.  As this
>>> change is uplifted to m-c, nightly builds for mac will also switch to run on
>>> taskcluster on Linux.  We will be testing to ensure that updates work as
>>> expected.  We don’t expect any impact to developers as this has been tested
>>> extensively on a project branch as well as by manual testing by PI.
>>>
>>>
>>>
>>> If you have questions, please contact us in #releng
>>>
>>>
>>>
>>> Enable OSX cross-compile builds as tier1 on mozilla-central
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1374422
>>>
>>>
>>>
>>> Land completed OSX cross compile Nightly code to mozilla-central
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1357867
>>>
>>>
>>>
>>> Land more Nightly OSX support to central
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1373326
>>>
>>>
>>>
>>> Kim Moir
>>>
>>> Mozilla Release Engineering
>>>
>>>
>>
>>
>
>
> ___
> Sheriffs mailing list
> sheri...@mozilla.org
> https://mail.mozilla.org/listinfo/sheriffs
>
___
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

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

[Chris Cooper]

On Wednesday, June 21, 2017 at 12:56:10 PM UTC-4, Chris Peterson wrote:
> i.e. Mike Shal's patch here fixed multiple 30% Talos regressions!
> 
> -: WORKSPACE ${WORKSPACE:=/home/worker/workspace}
> +: WORKSPACE ${WORKSPACE:=/builds/slave/try-m64-00}

We're still working to get that change into the task and/or TaskCluster worker, 
but yes, it's now an implementation detail. :)

To close the loop, that also means we won't need to strip the Mac nightlies by 
default. If we choose to start stripping nightlies to bring them in line with 
beta/release, that can be a separate discussion.

cheers,
--
coop
___
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: Intent to unship: moz*Frames attributes of HTMLVideoElement

[Chris Pearce]

On Monday, July 10, 2017 at 3:28:07 PM UTC+12, Randell Jesup wrote:
> >On Fri, Jul 7, 2017 at 11:54 AM, Jet Villegas  wrote:
> >
> >> What do we expect to break?
> >
> >
> >I can see that video quality auto adjusment which is based on these APIs
> >will become malfunction. But, I don't know is this a real use case that a
> >website implement video quality adjusment based on these APIs.
> 
> This will break a number of our internal mochitests.  I'm not sure
> without some checking if the standardized properties can replace them (I
> think the answer is no in some cases).  We could put them behind a pref
> for testing use.
> 
> >
> >> Who's out there using these APIs now?
> >>
> >
> 
> I do believe a number of webrtc services may use these; it's hard to be
> sure because many of them are not easily findable by searching github
> or search engines.
> 
> >There are some addons using these APIs to report media statistics. For our
> >internal use, there are only some test code using them. And I think the
> >VideoPlaybackQuality can be used to replace them since it provides a
> >similar feature.
> 
> In webrtc and related use, quality is not what these measure; we want to
> know if frames have arrived or been painted (generally using
> mozPaintedFrames).  There is one test using mozParsedFrames.
> 
> Before landing any deprecation warnings, you should check with the
> media/webrtc teams, and we may want to check how one or two external
> users are using it.
> 
> -- 
> Randell Jesup, Mozilla Corp
> remove "news" for personal email


I added these stats originally, and they are now mostly superseded by the stats 
provided by VideoPlaybackQuality. So I support their removal (in fact I 
suggested to Tim that he remove them).

Adding telemetry to learn how often these stats are used in the wild seems like 
a good idea. I'd be surprised if these are still used, but I'm happy to be 
proved wrong!

Randall: doesn't VideoPlaybackQuality support the use cases you're concerned 
about?



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

Re: More Rust code

[Chris Peterson]

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

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


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


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

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

Re: Phabricator Update, July 2017

[Chris Pearce]

What is the status of push-to-review support?

Chris.




On Wednesday, July 12, 2017 at 8:42:06 AM UTC+12, Mark Côté wrote:
> Hi all, here's a brief update on the project to deploy and integrate 
> Phabricator at Mozilla:
> 
> * Development Phabricator instance is up at
> https://mozphab.dev.mozaws.net/, authenticated via
> bugzilla-dev.allizom.org.
> 
> * Development, read-only UI for Lando (the new automatic-landing
> service) has been deployed.
> 
> * Work is proceeding on matching viewing restrictions on Phabricator
> revisions (review requests) to associated confidential bugs.
> 
> * Work is proceeding on the internals of Lando to land Phabricator
> revisions to the autoland Mercurial branch.
> 
> * Pre-release of Phabricator, without Lando, targeted for mid-August.
> 
> * General release of Phabricator and Lando targeted for late September 
> or early October.
> 
> * MozReview and Splinter turned off in early December.
> 
> I have a blog post up with many more details: 
> https://mrcote.info/blog/2017/07/11/phabricator-update/
> 
> More to come!
> 
> Mark
___
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

Intent to remove: EME support on insecure contexts

[Chris Pearce]

Summary:
Encrypted Media Extensions on insecure contexts (i.e. web sites served over 
non-HTTPS) is deprecated and will soon stop working in Firefox.

Sites wanting to use EME should switch to HTTPS if they have not already.

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

Link to standard:
https://www.w3.org/TR/encrypted-media/#privacy-secureorigin

The EME spec requires that EME only be usable from a secure context, e.g., on 
origins served over HTTPS, and not those served over HTTP.

EME is a powerful feature which makes use of sandboxed closed source CDMs which 
send messages (relayed via the JavaScript video player) to third party servers, 
and the risks are greater if the transport is not encrypted.

Chrome has already removed support for EME on insecure origins in M58:
https://www.chromestatus.com/feature/5724389932793856

Firefox is already logging a deprecation warning to the WebConsole when EME is 
used on an insecure origin (bug 1361000), and we have telemetry to track 
whether EME requests are made in a secure or insecure context:
https://mzl.la/2hsC7Dq

Timeframe:
I am hoping we can remove EME on insecure origins in Q4 2017 or Q1 2018.

Our telemetry shows about 8% of sites using EME are still in insecure contexts, 
and I'd prefer to see that number lower before we disable EME in insecure 
contexts. Given that Chrome have already removed their support for EME in 
insecure contexts, I expect this telemetry to show improvement quickly.
___
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


[

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

Firefox Nightly - now with twice as many builds a day!

[Chris AtLee]

Bug 1349227[1] landed a few days ago, which means we are now doing
"nightly" builds twice a day at 1000 and 2200 UTC.

The purpose of doing multiple nightlies is to get fixes out to users in
Europe, Africa and Asia sooner.

We have some concerns about possible impact to the build infrastructure, so
for now we're keeping an eye on load. We may need to revert if this causes
too much backlog.

In the meanwhile, enjoy a more up-to-date Nightly more often!

Please comment on the bug if there are other issues with doing multiple
nightlies a day.

Cheers,
Chris


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1349227
___
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: Follow up on clang-format

[Chris Pearce]

On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> Some of you may remember the discussion on clang-format and the `mach
> clang-format` command. What we have in place right now is very temporary
> but it is functional enough to give it a try. I have not put the effort
> into upstreaming my changes. Depending on the feedback I receive I will
> either:
> 
> * Finish my existing changes and upstream them
> * Remove the `mach clang-format` command altogether
> * Do nothing
> 
> I have personally found it useful. However I would like to hear from
> other people who have tried it to help me decide what to do next.
> 
> Anthony

I use `./mach clang-format` on basically every patch I write. It has eliminated 
the style nits that get picked up when people review my patches, at least when 
I remember to run it!

I've considered writing a commit hook to run `./mach clang-format` before every 
commit, but haven't gotten around to it...

`mach clang-format` is awesome, please don't remove it.

As others have pointed out, it doesn't always produce nice formatting, but it's 
at least consistent, and enforces the major style guide recommendations.

It's also liberating not having to waste brain power deciding how to format 
code.


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

Re: Follow up on clang-format

[Chris Pearce]

On Thursday, September 28, 2017 at 10:15:05 AM UTC+2, Chris Pearce wrote:
> On Friday, May 23, 2014 at 3:29:48 AM UTC+2, Anthony Jones wrote:
> > Some of you may remember the discussion on clang-format and the `mach
> > clang-format` command. What we have in place right now is very temporary
> > but it is functional enough to give it a try. I have not put the effort
> > into upstreaming my changes. Depending on the feedback I receive I will
> > either:
> > 
> > * Finish my existing changes and upstream them
> > * Remove the `mach clang-format` command altogether
> > * Do nothing
> > 
> > I have personally found it useful. However I would like to hear from
> > other people who have tried it to help me decide what to do next.
> > 
> > Anthony
> 
> I use `./mach clang-format` on basically every patch I write. It has 
> eliminated the style nits that get picked up when people review my patches, 
> at least when I remember to run it!
> 
> I've considered writing a commit hook to run `./mach clang-format` before 
> every commit, but haven't gotten around to it...
> 
> `mach clang-format` is awesome, please don't remove it.
> 
> As others have pointed out, it doesn't always produce nice formatting, but 
> it's at least consistent, and enforces the major style guide recommendations.
> 
> It's also liberating not having to waste brain power deciding how to format 
> code.
> 
> 
> cpearce.

Oh d'oh! Looks like I replied to an old thread, and the plan now is in fact to 
clang-format the entire tree after 57. Sweet as!
___
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

Setting expectations for sheriffing over the next month

[Chris Cooper]

Our code sheriffing bandwidth is greatly reduced right now. We
continue to train up the SoftVision (SV) sheriffing contractors to
assist with backouts and merges on a 24/7 basis, but they are not
ready yet.

What does this mean for you?

In the short term, this means the sheriffs can only guarantee one
merge per day. The sheriffing team (staff/community/contractors) will
try to keep the trees sufficiently green to *enable* a second daily
merge, but the merge may or may not happen, depending on the
availability of a senior sheriff to perform the merge.

As developers, you can help by being a little more conservative with
your code landings. Use autoland as much as possible, and make sure
your try results don't have obvious anomalies before pushing to
inbound. Most of you already do this, so thanks for that.

I know this may be inconvenient for people, but I appreciate your
patience during this interval. With any luck, we should be back to
normal in a few weeks.

If you do have any questions, please direct them to me.

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

Experimenting with a shared review queue for Core::Build Config

[Chris Cooper]

Many of the build peers have long review queues. I'm not convinced
that all of the review requests going to any particular build peer
need to be exclusive. We're going to try an experiment to see if we
can make this better for patch authors and reviewers alike. To this
end, we've set up a shared review queue for patches submitted to the
Core::Build Config module.

How to participate:

When you submit your next Build Config patch, simply select the new,
shared "user" core-build-config-revi...@mozilla.bugs as the reviewer
instead of a specific build peer. The build peers are watching this
new user, and will triage and review your patch accordingly.

This new arrangement should hopefully shorten patch queues for
specific reviewers and improve turnaround times for everybody. It also
has the added benefit of automatically working around absences,
vacations, and departures of build peers.

Note: this system still allows for targeting reviews to specific build
peers. Indeed, the build peers may do exactly that in triage if the
patch in question touches a particular sub-domain. However, I would
encourage patch authors to use the shared bucket unless you really
understand the sub-domain yourself or are collaborating directly with
a particular build peer.

As indicated in the subject, this is an experiment. I will monitor
patch queues and turnaround time over the next few months, and then
decide in January whether we should continue or try something else.

Thanks for your patience, and for trying something new.

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

Re: Experimenting with a shared review queue for Core::Build Config

[Chris Cooper]

On Wed, Oct 11, 2017 at 1:46 PM, Nathan Froyd  wrote:
> Does this user have a bugzilla :alias so that folks submitting patches
> via MozReview or similar can just write r=build-peer or something,
> rather than having to manually select the appropriate shared queue
> after submitting their patch for review?

I see this as an added efficiency, so I'll see how much effort it is
to set this up. The people behind MozReview are explicitly not
expending effort there right now in favor of phabricator though.

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

Re: Intent to unship: rel=preload for firefox 57

[Chris Mills]

> On 12 Oct 2017, at 08:43, Dragana Damjanovic  wrote:
> 
> rel=preload currently works only for cacheable resources. For web
> compatibility issues like bug Bug 1405761, rel=preload will be disabled on
> 57.

I’ve updated the MDN docs about preload to make this clear.

> 
> I intent to land rel=preload for non-cacheable resources as well in next
> couple of days. This will be on Firefox 58 and I will turn rel=preload back
> on when this lands.

What’s the bug number to track this work?

thanks,

Chris
___
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

“approval required” for changes affecting CI infrastructure

[Chris AtLee]

To ensure a successful Firefox 57 release, teams responsible for Firefox CI
& release infrastructure have adopted an “approval required” policy for
changes that could impact Firefox development or release. This includes
systems like buildbot, Taskcluster services, puppet, hg, product delivery,
and in-tree changes that could impact task scheduling.

If you have a change you’d like to land that impacts one of the above
systems, or you think could impact the infrastructure, please let the
firefox-ci@ list know. Most changes are fine to land, we just want to be
aware of what’s changing in the overall system in the leadup to 57.

If you don’t hear a response back in 24h, you can assume that your proposal
is fine, and proceed to land it.

Thanks in advance,
Chris
___
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

How to request documentation for new features or report problems on MDN

[Chris Mills]

Hi all,

I am sending a mail around to explain how to request MDN documentation for new 
features you are working on (e.g. new web platform features, web extensions 
features, devtools features), or report docs problems. We've had a fair few 
people show a misunderstanding of how this process works recently.

TL;DR
-

There are two main ways to ask for docs on MDN:

* Requesting docs by adding the "dev-doc-needed" keyword to an engineering bug
* Reporting problems by filing a bug against the "Developer Documentation" 
product 
(https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Documentation)

They are not equivalent.

* "dev-doc-needed" means "some code in Firefox has changed, and as a result the 
docs need to be updated"
* a "Developer Documentation" bug means "some docs on MDN are 
wrong/misleading/incomplete"

Requesting docs
---

So, if you are working on a bug to add a new feature or update an existing 
feature, and it will require documentation changes, add the keyword 
"dev-doc-needed" to it. This keyword doesn't mean "we will document this NOW". 
It means "we will document this in the future, when appropriate".

The way the system works is that when "dev-doc-needed" is put on a bug, as soon 
as that bug is then resolved our system picks it up and then we will act on it 
as appropriate (by documenting the feature, or maybe just ignoring it if it was 
WONTFIX’ed, etc.)

Using this system, we are ready to document new features, if and when they are 
needed. Please add "dev-doc-needed" for any such features you are working on. 
It makes our lives much easier. Thanks!

Note: You can set "dev-doc-needed" any time, but we will only look at it once 
the bug it's attached to is resolved. Once the bug is resolved we'll schedule 
time to update the docs for it, always aiming to have the docs updated before 
the version of Firefox containing the change is released (hopefully before that 
Firefox is in beta, but we don't always manage that).

Note: Feature removal/unship bugs should also have "dev-doc-needed" added — 
these are still changes that require docs updates. 

Note: We don't add notes in our docs to cover bugs/regressions that crop up. 
These are often shortlived, and we don't have the bandwidth for this.

Reporting problems
--

If you notice a problem of some kind with an MDN doc, such as a doc that:

* should really be added to make a resource complete, but is not linked to a 
specific feature addition
* is located in the wrong place
* contains a code, spelling or grammar error
* looks outdated
* contains spam
* etc.

Please file a new bug to report it, under the "Developer Documentation" product.

We triage these bugs weekly, and prioritise and handle them in a similar kind 
of way to engineering bugs.

Important: Don't file "Developer Documentation" bugs for feature additions that 
already being tracked in an engineering bug. Instead, add the "dev-doc-needed" 
keyword to the engineering bug. We've had a few duplications recently because 
of this.

Many thanks!

Chris Mills
MDN content lead & writers' team manager || Mozilla
developer.mozilla.org || MDN Web Docs
cmi...@mozilla.com || @chrisdavidmills

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

Re: How to request documentation for new features or report problems on MDN

[Chris Mills]

Yes, what sheppy said ;-)

Chris Mills
MDN content lead & writers' team manager || Mozilla
developer.mozilla.org || MDN Web Docs
cmi...@mozilla.com || @chrisdavidmills

> On 17 May 2018, at 05:27, Eric Shepherd (Sheppy)  
> wrote:
> 
> Yes. Always, you're welcome to make needed changes yourself. If you want a 
> writer to take a look after you're done, to be sure everything is in the 
> right place (or to double-check your grammar), that's certainly no problem.
> 
> On Wed, May 16, 2018 at 6:40 PM Martin Thomson  wrote:
> Hi Chris,
> 
> I assume that "just fix it" is still a viable alternative to the processes
> you describe.  For small things, that might be easier for all involved.
> On Thu, May 17, 2018 at 5:39 AM Chris Mills  wrote:
> 
> > Hi all,
> 
> > I am sending a mail around to explain how to request MDN documentation
> for new features you are working on (e.g. new web platform features, web
> extensions features, devtools features), or report docs problems. We've had
> a fair few people show a misunderstanding of how this process works
> recently.
> 
> > TL;DR
> > -
> 
> > There are two main ways to ask for docs on MDN:
> 
> > * Requesting docs by adding the "dev-doc-needed" keyword to an
> engineering bug
> > * Reporting problems by filing a bug against the "Developer
> Documentation" product (
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Documentation
> )
> 
> > They are not equivalent.
> 
> > * "dev-doc-needed" means "some code in Firefox has changed, and as a
> result the docs need to be updated"
> > * a "Developer Documentation" bug means "some docs on MDN are
> wrong/misleading/incomplete"
> 
> > Requesting docs
> > ---
> 
> > So, if you are working on a bug to add a new feature or update an
> existing feature, and it will require documentation changes, add the
> keyword "dev-doc-needed" to it. This keyword doesn't mean "we will document
> this NOW". It means "we will document this in the future, when appropriate".
> 
> > The way the system works is that when "dev-doc-needed" is put on a bug,
> as soon as that bug is then resolved our system picks it up and then we
> will act on it as appropriate (by documenting the feature, or maybe just
> ignoring it if it was WONTFIX’ed, etc.)
> 
> > Using this system, we are ready to document new features, if and when
> they are needed. Please add "dev-doc-needed" for any such features you are
> working on. It makes our lives much easier. Thanks!
> 
> > Note: You can set "dev-doc-needed" any time, but we will only look at it
> once the bug it's attached to is resolved. Once the bug is resolved we'll
> schedule time to update the docs for it, always aiming to have the docs
> updated before the version of Firefox containing the change is released
> (hopefully before that Firefox is in beta, but we don't always manage that).
> 
> > Note: Feature removal/unship bugs should also have "dev-doc-needed" added
> — these are still changes that require docs updates.
> 
> > Note: We don't add notes in our docs to cover bugs/regressions that crop
> up. These are often shortlived, and we don't have the bandwidth for this.
> 
> > Reporting problems
> > --
> 
> > If you notice a problem of some kind with an MDN doc, such as a doc that:
> 
> > * should really be added to make a resource complete, but is not linked
> to a specific feature addition
> > * is located in the wrong place
> > * contains a code, spelling or grammar error
> > * looks outdated
> > * contains spam
> > * etc.
> 
> > Please file a new bug to report it, under the "Developer Documentation"
> product.
> 
> > We triage these bugs weekly, and prioritise and handle them in a similar
> kind of way to engineering bugs.
> 
> > Important: Don't file "Developer Documentation" bugs for feature
> additions that already being tracked in an engineering bug. Instead, add
> the "dev-doc-needed" keyword to the engineering bug. We've had a few
> duplications recently because of this.
> 
> > Many thanks!
> 
> > Chris Mills
> > MDN content lead & writers' team manager || Mozilla
> > developer.mozilla.org || MDN Web Docs
> > cmi...@mozilla.com || @chrisdavidmills
> 
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
> -- 
> 
> Eric Shepherd
> Senior Technical Writer
> Mozilla
> Blog: http://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
> Check my Availability

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

Re: Removing tinderbox-builds from archive.mozilla.org

[Chris AtLee]

The discussion about what to do about these particular buildbot builds has
naturally shifted into a discussion about what kind of retention policy is
appropriate for CI builds.

I believe that right now we keep all CI build artifacts for 1 year. Nightly
and release builds are kept forever. There's certainly an advantage to
keeping the CI builds, as they assist in bisecting regressions. However,
they become less useful over time.

IMO, it's not reasonable to keep CI builds around forever, so the question
is then how long to keep them? 1 year doesn't quite cover a full ESR cycle,
would 18 months be sufficient for most cases?

Alternatively, we could investigate having different expiration policies
for different type of artifacts. My assumption is that the Firefox binaries
for the opt builds are the most useful over the long term, and that other
build configurations and artifacts are less useful. How accurate is that
assumption?

Archiving these artifacts into Glacier would cut the cost of storing them
significantly, but also make them much harder to access. It can take 3-5
hours to retrieve objects from Glacier, and we would need to implement some
API or process to request access to archived objects.


On Thu, 17 May 2018 at 10:33, Mike Kaply  wrote:

> Can we move the builds temporarily and see if it affects workflows over a
> few months and if not, then remove them?
>
> Mike
>
> On Thu, May 17, 2018 at 9:22 AM, Tom Ritter  wrote:
>
> > I agree with ekr in general, but I would also be curious to discover
> > what failures we would experience in practice and how we could
> > overcome them.
> >
> > I think many of the issues experienced with local builds are
> > preventable by doing a TC-like build; just build in a docker container
> > (for Linux/Mac) and auto-build any toolchains needed. (Which would be
> > part of bisect in the cloud automatically.) I've been doing this
> > locally lately and it is not a friendly process right now though.
> >
> > Of course on Windows it's an entirely different story. But one more
> > reason to pursue clang-cl builds on Linux ;)
> >
> > -tom
> >
> >
> > On Tue, May 15, 2018 at 12:53 PM, Randell Jesup 
> > wrote:
> > >>On 5/11/18 7:06 PM, Gregory Szorc wrote:
> > >>> Artifact retention and expiration boils down to a
> > >>> trade-off between the cost of storage and the convenience of
> accessing
> > >>> something immediately (as opposed to waiting several dozen minutes to
> > >>> populate the cache).
> > >>
> > >>Just to be clear, when doing a bisect, one _can_ just deal with local
> > >>builds.  But the point is that then it takes tens of minutes per build
> as
> > >>you point out.  So a bisect task that might otherwise take 10-15
> minutes
> > >>total (1 minute per downloaded build) ends up taking hours...
> > >
> > > Also (as others have pointed out) going too far back (often not that
> > > far) may run you into tool differences that break re-building old revs.
> > > Hopefully you don't get variable behavior, just a failure-to-build at
> > > some point.  I'm not sure how much Rust has made this worse.
> > >
> > > --
> > > Randell Jesup, Mozilla Corp
> > > remove "news" for personal email
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 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: Removing tinderbox-builds from archive.mozilla.org

[Chris AtLee]

On Sun, 20 May 2018 at 19:40, Karl Tomlinson  wrote:

> On Fri, 18 May 2018 13:13:04 -0400, Chris AtLee wrote:

> > IMO, it's not reasonable to keep CI builds around forever, so the
question
> > is then how long to keep them? 1 year doesn't quite cover a full ESR
cycle,
> > would 18 months be sufficient for most cases?
> >
> > Alternatively, we could investigate having different expiration policies
> > for different type of artifacts. My assumption is that the Firefox
binaries
> > for the opt builds are the most useful over the long term, and that
other
> > build configurations and artifacts are less useful. How accurate is that
> > assumption?

> Having a subset of builds around for longer would be more useful
> to me than having all builds available for a shorter period.

> The nightly builds often include large numbers of changesets,
> sometimes collected over several days, and so it becomes hard to
> identify which code change modified a particular behavior.

> I always use opt builds for regression testing, and so your
> assumption is consistent with my experience.

> I assume there are more pgo builds than nightly builds, but fewer
> than all opt builds.  If so, then having a long expiration policy
> on pgo builds could be a helpful way to reduce storage costs but
> maintain the most valuable builds.

Here's a bit of a strawman proposal...What if we keep the
{mozilla-central,mozilla-inbound,autoland}-{linux,linux64,macosx64,win32,win64}{,-pgo}/
directories in tinderbox-builds for now, and delete all the others. Does
that cover the majority of the use cases for wanting to access these old
builds?

I'm guessing the historical builds for old esr branches aren't useful now.
Nor are the mozilla-aurora, mozilla-beta, mozilla-release, or b2g-inbound
builds.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing tinderbox-builds from archive.mozilla.org

[Chris AtLee]

On Tue, 29 May 2018 at 14:21, L. David Baron  wrote:
>
> On Monday 2018-05-28 15:52 -0400, Chris AtLee wrote:
> > Here's a bit of a strawman proposal...What if we keep the
> > {mozilla-central,mozilla-inbound,autoland}-{linux,linux64,macosx64,win32,win64}{,-pgo}/
> > directories in tinderbox-builds for now, and delete all the others. Does
> > that cover the majority of the use cases for wanting to access these old
> > builds?
> >
> > I'm guessing the historical builds for old esr branches aren't useful now.
> > Nor are the mozilla-aurora, mozilla-beta, mozilla-release, or b2g-inbound
> > builds.
>
> This seems reasonable to me, with the one caveat that I think
> b2g-inbound belongs in the other bucket.  It was essentially used as
> another peer to mozilla-inbound and autoland, and while many of the
> changes landed there were b2g-only, many of them weren't, and may
> have caused regressions that affect products that we still maintain.

Ok, we can do that.

For mobile, I haven't heard anybody express a desire to keep around
old CI builds in
https://archive.mozilla.org/pub/mobile/tinderbox-builds/, so I'm
planning to have those deleted in July.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Launch of Phabricator and Lando for mozilla-central

[Chris AtLee]

This is really great news, I'm really excited to start using it!

Automated landings from code review is such a game changer for
productivity and security.

Congrats to everyone involved.

Cheers,
Chris

On Wed, 6 Jun 2018 at 11:01, Mark Côté  wrote:
>
> The Engineering Workflow team is happy to announce the release of Phabricator 
> and Lando for general use. Going forward, Phabricator will be the primary 
> code-review tool for modifications to the mozilla-central repository, 
> replacing both MozReview and Splinter. Lando is an all-new automatic-landing 
> system that works with Phabricator. This represents about a year of work 
> integrating Phabricator with our systems and building out Lando. Phabricator 
> has been in use by a few teams since last year, and Lando has been used by 
> the Engineering Workflow team for several weeks and lately has successfully 
> landed a few changesets to mozilla-central.
>
> Phabricator is a suite of applications, but we are primarily using the 
> code-review tool, called Differential, which will be taking the place of 
> MozReview and Splinter. Bug tracking will continue to be done with Bugzilla, 
> which is integrated with Phabricator. You will log into Phabricator via 
> Bugzilla. We will soon begin sunsetting MozReview, and Splinter will be made 
> read-only (or replaced with another patch viewer). An upcoming post will 
> outline the plans for the deprecation, archival, and decommission of 
> MozReview, with Splinter to follow.
>
> I also want to thank Phacility, the company behind Phabricator, who provided 
> both excellent support and work on Phabricator itself to meet our 
> requirements in an exceptionally helpful and responsive way.
>
> User documentation on Phabricator catered specifically to Mozillians can be 
> found at https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html. 
> It is also linked from within Phabricator, in the left-hand menu on the home 
> page.
>
> User documentation on Lando can be found at 
> https://moz-conduit.readthedocs.io/en/latest/lando-user.html.
>
> MDN documentation is currently being updated.
>
> At the moment, Phabricator can support confidential revisions when they are 
> associated with a confidential bug, that is, a bug with one or more security 
> groups applied. Lando, however, cannot currently land these revisions. This 
> is a limitation we plan to fix in Q3. You can follow 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1443704 for developments. See 
> http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#landing-patches
>  for our recommendations on landing patches in Phabricator without Lando.
>
> Similarly, there are two other features which are not part of initial launch 
> but will follow in subsequent releases:
> * Stacked revisions. If you have a stack of revisions, that is, two or more 
> revisions with parent-child relationships, Lando cannot land them all at 
> once.  You will need to individually land them. This is filed as 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1457525.
> * Try support. Users will have to push to the Try server manually until this 
> is implemented. See https://bugzilla.mozilla.org/show_bug.cgi?id=1466275.
>
> Finally, we realize there are a few oddities with the UI that we will also be 
> fixing in parallel with the new features. See 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1466120.
>
> The documentation lists several ways of getting in touch with the Engineering 
> Workflow team, but #phabricator and #lando on IRC are good starting points.
>
> ___
> 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: block audible autoplay media intervention

[Chris Pearce]

Intent to ship: block audible autoplay media intervention

SUMMARY:

We intend to change the behaviour of HTMLMediaElement to block autoplay of 
audible audio and video in Firefox on desktop and mobile.

We are not going to block WebAudio at the same time. While we do plan to block 
audible autoplay of WebAudio content in the near future, we have not finalized 
our WebAudio blocking logic or intended ship date for blocking WebAudio.


TIMELINE:

We intend to run shield studies on the user impact of enabling HTMLMediaElement 
autoplay blocking. If those go well we hope to ship in Firefox 63 (2018-10-23) 
or Firefox 64 (2018-12-11). Upon conclusion of our experiments, I’ll follow up 
here with a confirmed ship date for this feature.

We hope to block autoplay in WebAudio in a release soon after, hopefully 
Firefox 64 or 65.


DETAILS:

We intend to block autoplay of HTMLMediaElement in tabs which haven't had user 
interaction. Web authors should assume that they require a user gesture (mouse 
click on a "play" button for example) in order to play audible media.

HTMLMediaElements with a "muted" attribute or "volume=0" are still allowed to 
play.

As with other browsers implementing this feature, we express playback being 
blocked by rejecting the promise returned by HTMLMediaElement.play(). Web 
authors should always check whether the promise returned by 
HTMLMediaElement.play() is rejected, and handle that case accordingly.

We also plan to allow users to create their own whitelist of sites which they 
trust to autoplay.

We are planning to experiment via shield studies with prompting users to 
approve/block playback on sites that try to autoplay before receiving user 
interaction.


ADVICE FOR WEB AUTHORS:

In general, the advice that applies to other browsers [1][2] with respect to 
autoplaying media will apply to Firefox as well; you cannot assume that you can 
just call HTMLMediaElement.play() for audible media and expect it to always 
play. You should always check whether the play promise is rejected, and handle 
that case accordingly.

For example:

var promise = document.querySelector('video').play();

if (promise !== undefined) {
promise.catch(error => {
// Auto-play was prevented
// Show a UI element to let the user manually start playback
}).then(() => {
// Auto-play started
});
}

(This example comes from WebKit’s announcement on blocking autoplay [2])

To test block autoplay in Firefox 63 (currently in Firefox Nightly channel), 
download the latest Nightly and open about:config in the URL bar and set the 
preferences:

media.autoplay.enabled=false
media.autoplay.enabled.user-gestures-needed=true
media.autoplay.ask-permission=true


Tracking bug: (block-autoplay) 
https://bugzilla.mozilla.org/show_bug.cgi?id=1376321


If you find bugs, please file them via this link and CC or need-info me 
(cpearce), and mark them blocking bug 1376321:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Audio%2FVideo%3A%20Playback


I will follow up with a confirmed ship date for block audible autoplay in 
Firefox once we have one.



[1] https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
[2] https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

Hi Mounir,

Replies inline below...


On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri  wrote:

> Hi Chris,
>
> Very excited to see Firefox going forward with autoplay blocking. A couple
> of comments inline.
>
> On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote:
> > DETAILS:
> >
> > We intend to block autoplay of HTMLMediaElement in tabs which haven't
> > had user interaction. Web authors should assume that they require a user
> > gesture (mouse click on a "play" button for example) in order to play
> > audible media.
>
> I assume you will not allow autoplay when navigating into the same
> website? What about iframes? Will they be allowed to autoplay if the main
> frame is allowed to? Will the feature policy be used instead?
>
>
A gesture in any document in the document hierarchy gesture activates the
top level document, and a document uses the top level document's gesture
activation status to determine whether it can play (our implementation
actually differs a bit, but this is the effective behaviour). Gesture
activation status isn't preserved across navigation. So if the top level
document navigates, the incoming document hierarchy won't be able to
autoplay. If a non-top-level document navigates, the new document in the
iframe will still use the top-level document's gesture activation status,
and so the iframe's new content document will be able to autoplay.



> > HTMLMediaElements with a "muted" attribute or "volume=0" are still
> > allowed to play.
>
> Chrome and Safari allows autoplay only when the playback is muted. The
> spec allows side effect for setting `muted = false;`. What will happen for
> a website that changes the volume from 0 to something else?
>
>

If an HTMLMediaElement starts playing with muted/volume=0 and then script
sets it to unmuted/volume>0, then we'll pause the media.



> Also, will autoplay be allowed when the video has no audio track?
>
>
>
Our autoplay logic ignores whether the media resource has an audio track;
it makes our implementation simpler, and if an author knows a media should
be inaudible, they can set the muted attribute. So a video element playing
a media resource with no audio track and without the muted attribute would
still be blocked.


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

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote:
> On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote:
> > Hi Mounir,
> > 
> > Replies inline below...
> > 
> > 
> > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri  wrote:
> > 
> > > Hi Chris,
> > >
> > > Very excited to see Firefox going forward with autoplay blocking. A couple
> > > of comments inline.
> > >
> > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote:
> > > > DETAILS:
> > > >
> > > > We intend to block autoplay of HTMLMediaElement in tabs which haven't
> > > > had user interaction. Web authors should assume that they require a user
> > > > gesture (mouse click on a "play" button for example) in order to play
> > > > audible media.
> > >
> > > I assume you will not allow autoplay when navigating into the same
> > > website? What about iframes? Will they be allowed to autoplay if the main
> > > frame is allowed to? Will the feature policy be used instead?
> > >
> > >
> > A gesture in any document in the document hierarchy gesture activates the
> > top level document, and a document uses the top level document's gesture
> > activation status to determine whether it can play (our implementation
> > actually differs a bit, but this is the effective behaviour). Gesture
> > activation status isn't preserved across navigation. So if the top level
> > document navigates, the incoming document hierarchy won't be able to
> > autoplay. If a non-top-level document navigates, the new document in the
> > iframe will still use the top-level document's gesture activation status,
> > and so the iframe's new content document will be able to autoplay.
> 
> With autoplay coming from third party content, do you consider using Feature 
> Policy to block cross origin iframes by default?


I won't rule out doing something in the spirit providing a way for sites to 
control whether subframes are allowed to autoplay in future, but we won't be 
doing it as part of our MVP.


> > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still
> > > > allowed to play.
> > >
> > > Chrome and Safari allows autoplay only when the playback is muted. The
> > > spec allows side effect for setting `muted = false;`. What will happen for
> > > a website that changes the volume from 0 to something else?
> > >
> > >
> > 
> > If an HTMLMediaElement starts playing with muted/volume=0 and then script
> > sets it to unmuted/volume>0, then we'll pause the media.
> 
> The volume=0 behaviour isn't compatible with Blink and WebKit. Would it be 
> worth only use muted for consistency between browsers?

This code gives me the impression that WebKit does in fact block volume > 0 
media:
https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303

So maybe Blink should consider changing to be consistent with other browsers? ;)


> > > Also, will autoplay be allowed when the video has no audio track?
> > >
> > >
> > >
> > Our autoplay logic ignores whether the media resource has an audio track;
> > it makes our implementation simpler, and if an author knows a media should
> > be inaudible, they can set the muted attribute. So a video element playing
> > a media resource with no audio track and without the muted attribute would
> > still be blocked.
> 
> FWIW, WebKit uses the audio track availability and Blink intends to do this 
> at some point.


I actually implemented this, landed it, and then ended up reverting it.

The main problem here is if HTMLMediaElement.play() is called before the load 
algorithm has reached readyState>=HAVE_METADATA, you won't know whether the 
media you're loading has audio tracks.

If you hit this case, you have two options; decide whether to block immediately 
based on incomplete information, or return the promise and wait until you reach 
loadedmetadata before deciding whether to play.

If you decide based on incomplete information you become racy; the decision you 
make on incomplete information may contradict the decision you'd make based on 
more complete information when the load is further along, and network loads are 
inherently racy. That seems bad.

If you return the promise and yield control to JS you run into compat issues. 
As Jean-Yves mentioned, some sites expect that HTMLMediaElement.play() 
synchronously sets the paused attribute to false and enqueues tasks to fire 
"play", "playing&q

Re: Intent to ship: block audible autoplay media intervention

[Chris Pearce]

On Saturday, July 7, 2018 at 5:04:28 AM UTC+12, Mounir Lamouri wrote:
> On Fri, 6 Jul 2018, at 00:49, Chris Pearce wrote:
> > On Friday, July 6, 2018 at 3:10:58 AM UTC+12, Mounir Lamouri wrote:
> > > On Wed, 4 Jul 2018, at 18:22, Chris Pearce wrote:
> > > > Hi Mounir,
> > > > 
> > > > Replies inline below...
> > > > 
> > > > 
> > > > On Thu, Jul 5, 2018 at 2:56 AM, Mounir Lamouri  
> > > > wrote:
> > > > 
> > > > > Hi Chris,
> > > > >
> > > > > Very excited to see Firefox going forward with autoplay blocking. A 
> > > > > couple
> > > > > of comments inline.
> > > > >
> > > > > On Tue, 3 Jul 2018, at 19:38, Chris Pearce wrote:
> > > > > > DETAILS:
> > > > > >
> > > > > > We intend to block autoplay of HTMLMediaElement in tabs which 
> > > > > > haven't
> > > > > > had user interaction. Web authors should assume that they require a 
> > > > > > user
> > > > > > gesture (mouse click on a "play" button for example) in order to 
> > > > > > play
> > > > > > audible media.
> > > > >
> > > > > I assume you will not allow autoplay when navigating into the same
> > > > > website? What about iframes? Will they be allowed to autoplay if the 
> > > > > main
> > > > > frame is allowed to? Will the feature policy be used instead?
> > > > >
> > > > >
> > > > A gesture in any document in the document hierarchy gesture activates 
> > > > the
> > > > top level document, and a document uses the top level document's gesture
> > > > activation status to determine whether it can play (our implementation
> > > > actually differs a bit, but this is the effective behaviour). Gesture
> > > > activation status isn't preserved across navigation. So if the top level
> > > > document navigates, the incoming document hierarchy won't be able to
> > > > autoplay. If a non-top-level document navigates, the new document in the
> > > > iframe will still use the top-level document's gesture activation 
> > > > status,
> > > > and so the iframe's new content document will be able to autoplay.
> > > 
> > > With autoplay coming from third party content, do you consider using 
> > > Feature Policy to block cross origin iframes by default?
> > 
> > 
> > I won't rule out doing something in the spirit providing a way for sites 
> > to control whether subframes are allowed to autoplay in future, but we 
> > won't be doing it as part of our MVP.
> 
> To clarify, your MVP will allow subframes to autoplay if the main frame can, 
> right?
> 


That's correct. If any document in the hierarchy is gesture activated, the 
entire hierarchy is activated.


> > > > > > HTMLMediaElements with a "muted" attribute or "volume=0" are still
> > > > > > allowed to play.
> > > > >
> > > > > Chrome and Safari allows autoplay only when the playback is muted. The
> > > > > spec allows side effect for setting `muted = false;`. What will 
> > > > > happen for
> > > > > a website that changes the volume from 0 to something else?
> > > > >
> > > > >
> > > > 
> > > > If an HTMLMediaElement starts playing with muted/volume=0 and then 
> > > > script
> > > > sets it to unmuted/volume>0, then we'll pause the media.
> > > 
> > > The volume=0 behaviour isn't compatible with Blink and WebKit. Would it 
> > > be worth only use muted for consistency between browsers?
> > 
> > This code gives me the impression that WebKit does in fact block volume 
> > > 0 media:
> > https://github.com/WebKit/webkit/blob/2d78ab563d64545ead630115bcd55047d0400fac/Source/WebCore/html/MediaElementSession.cpp#L303
> > 
> > So maybe Blink should consider changing to be consistent with other 
> > browsers? ;)
> 
> That's interesting. We spec'd something in HTML and Safari did not mention 
> this. It's not in their documentation nor ours. What's the benefit of 
> allowing volume=0 to autoplay?


Setting volume to 0 is another easy way to make videos inaudible, and we want 
inaudible video to be able to autoplay. So I'd flip that question around and 

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