Re: Figuring out and controlling what tasks run before first paint

[Gregory Szorc]

On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione  wrote:

> One of my biggest frustrations in profiling startup performance has been
> the fact that exactly which code runs during before or after first paint
> changes based on arbitrary timing factors. If I make a 5ms improvement to
> one section of code, a 100ms chunk of code winds up running after first
> paint rather than before. If I make a 5ms improvement to another section of
> code, a 150ms chunk of code winds up running *before* first paint rather
> than after. This also shows up in the ts_paint timings on talos, where we
> have a fairly consistent cluster of high times, a fairly consistent cluster
> of low times, and very little in-between.
>
> Presumably, if we're OK with these chunks *ever* running after first
> paint, then they should always run after first paint. And vice versa.
>
> I've made various attempts to get a handle on this, but never with much
> success. The last time, I got as far as fixing the broken TaskTracer build
> before I finally gave up trying to find a useful way to analyze the data.
> What I'd really like is a handle on what tasks are run, when, who schedule
> them (and when), and what code they run.
>
> After that, I'd ideally like to find a way to run async tasks during
> startup so that I'm guaranteed which parts run before first paint and which
> run after.
>
> Has anyone else made any progress on this front? Are there any other tools
> that I'm overlooking? Is there a sensible path forward?
>

This reminded me of an old thread from 2013:
https://groups.google.com/d/msg/mozilla.dev.platform/oKRBRqQbalk/D_YYWex83X4J

I'm pretty sure that thread eventually led to
toolkit/components/asyncshutdown (which Yoric wrote). That's a really nifty
mechanism for managing component shutdown. IIRC it helped eliminate a
number of race conditions, edge cases, and bad practices (like event loop
spinning).

AFAIK we never replicated that feature to startup or came up with a more
modern/generic mechanism to manage components and their complex
dependencies throughout their lifetime. (It is a hard problem after all.)
Re-reading that old thread and your issues here, it might be worth
re-visiting those grand ideas from 2013.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Boris Zbarsky]

On 8/8/17 6:40 PM, Blake Kaplan wrote:

What part of the current set-up is rocket science?


Debugging pageload.  Especially pageload with no session history.


In multi, there's
definitely a problem figuring out which process is the active one (though
tooltips when hovering over tabs can help).


That doesn't help when you want a no-history load.  You might get an 
entirely new process.  Or one of your existing processes, who knows.



remote tab, you can load pages in that tab and we'll stay in the same process.


Right, but then you have to worry about the interactions of the unload 
and new load...



That means that loading about:blank explicitly, attaching to that tab's
process, setting breakpoints, and loading the page should do the right thing.


Hmm.  Do we load about:blank from the url bar in a content process?

-Boris

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

Re: Figuring out and controlling what tasks run before first paint

[Kris Maglione]

On Tue, Aug 08, 2017 at 06:09:05PM -0700, Robert Strong wrote:

One thing that comes to mind is how some code registers app specific
observers so the code runs after the UI is displayed.
...

Perhaps having a single category for after UI has been displayed that
components can specify in their manifests so they are initialized at that
time similar to how profile-after-change is typically used. This way they
wouldn't have to initialize just to register an observer so the work
happens after theUI is displayed.


The running after first paint part is probably fairly easy. For 
most of the cases I'm thinking of, a promise that resolves at 
the right time, in the middle of a promise chain, should be 
enough.


It's the figuring out what's causing things to run, and ensuring 
that things get run before first paint that's more of a problem. 
We do a lot of async things at startup, like file reads and 
off-thread parses. A lot of those things wind up split up into 
multiple operations, and the event loop is so saturated during 
startup if they miss a chance to run, they often wind up running 
after first paint. If we do something like spin the event loop 
to make sure they run in time, extra things run before paint.


So perhaps it would be a fairly simple problem if we ensured 
that everything that runs during startup explicitly defers 
things that don't need to run before paint. But at this point, 
it's so hard to get a hold on what's being scheduled and why 
that I don't even know where to start.



On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione  wrote:


One of my biggest frustrations in profiling startup performance has been
the fact that exactly which code runs during before or after first paint
changes based on arbitrary timing factors. If I make a 5ms improvement to
one section of code, a 100ms chunk of code winds up running after first
paint rather than before. If I make a 5ms improvement to another section of
code, a 150ms chunk of code winds up running *before* first paint rather
than after. This also shows up in the ts_paint timings on talos, where we
have a fairly consistent cluster of high times, a fairly consistent cluster
of low times, and very little in-between.

Presumably, if we're OK with these chunks *ever* running after first
paint, then they should always run after first paint. And vice versa.

I've made various attempts to get a handle on this, but never with much
success. The last time, I got as far as fixing the broken TaskTracer build
before I finally gave up trying to find a useful way to analyze the data.
What I'd really like is a handle on what tasks are run, when, who schedule
them (and when), and what code they run.

After that, I'd ideally like to find a way to run async tasks during
startup so that I'm guaranteed which parts run before first paint and which
run after.

Has anyone else made any progress on this front? Are there any other tools
that I'm overlooking? Is there a sensible path forward?

Thanks.

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

Re: More Rust code

[Ehsan Akhgari]

On 08/08/2017 11:32 AM, Jeff Muizelaar wrote:

On Mon, Aug 7, 2017 at 6:12 PM, Mike Hommey  wrote:

   Note that the tp5n main_startup_fileio reflects the resulting size of
   xul.dll, which also impacts the installer size:
  32-bits   64-bits
   MSVC (PGO):   37904383  40803170
   clang-cl: 39537860  40561849
   clang-cl -O2: 41976097  43338891

FWIW, https://bugs.llvm.org//show_bug.cgi?id=26299 is the metabug for
tracking improvements to x86-32 code size.
And the equivalent bug on the Chromium side: 
https://bugs.chromium.org/p/chromium/issues/detail?id=457078

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

Re: Figuring out and controlling what tasks run before first paint

[Robert Strong]

One thing that comes to mind is how some code registers app specific
observers so the code runs after the UI is displayed.
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#180
https://dxr.mozilla.org/mozilla-central/source/devtools/shared/system.js#24
https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/system/xul-app.jsm#48

Perhaps having a single category for after UI has been displayed that
components can specify in their manifests so they are initialized at that
time similar to how profile-after-change is typically used. This way they
wouldn't have to initialize just to register an observer so the work
happens after theUI is displayed.
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.manifest#12

Robert

On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione  wrote:

> One of my biggest frustrations in profiling startup performance has been
> the fact that exactly which code runs during before or after first paint
> changes based on arbitrary timing factors. If I make a 5ms improvement to
> one section of code, a 100ms chunk of code winds up running after first
> paint rather than before. If I make a 5ms improvement to another section of
> code, a 150ms chunk of code winds up running *before* first paint rather
> than after. This also shows up in the ts_paint timings on talos, where we
> have a fairly consistent cluster of high times, a fairly consistent cluster
> of low times, and very little in-between.
>
> Presumably, if we're OK with these chunks *ever* running after first
> paint, then they should always run after first paint. And vice versa.
>
> I've made various attempts to get a handle on this, but never with much
> success. The last time, I got as far as fixing the broken TaskTracer build
> before I finally gave up trying to find a useful way to analyze the data.
> What I'd really like is a handle on what tasks are run, when, who schedule
> them (and when), and what code they run.
>
> After that, I'd ideally like to find a way to run async tasks during
> startup so that I'm guaranteed which parts run before first paint and which
> run after.
>
> Has anyone else made any progress on this front? Are there any other tools
> that I'm overlooking? Is there a sensible path forward?
>
> Thanks.
> ___
> 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

Figuring out and controlling what tasks run before first paint

[Kris Maglione]

One of my biggest frustrations in profiling startup performance 
has been the fact that exactly which code runs during before or 
after first paint changes based on arbitrary timing factors. If 
I make a 5ms improvement to one section of code, a 100ms chunk 
of code winds up running after first paint rather than before. 
If I make a 5ms improvement to another section of code, a 150ms 
chunk of code winds up running *before* first paint rather than 
after. This also shows up in the ts_paint timings on talos, 
where we have a fairly consistent cluster of high times, a 
fairly consistent cluster of low times, and very little 
in-between.


Presumably, if we're OK with these chunks *ever* running after 
first paint, then they should always run after first paint. And 
vice versa.


I've made various attempts to get a handle on this, but never 
with much success. The last time, I got as far as fixing the 
broken TaskTracer build before I finally gave up trying to find 
a useful way to analyze the data. What I'd really like is a 
handle on what tasks are run, when, who schedule them (and 
when), and what code they run.


After that, I'd ideally like to find a way to run async tasks 
during startup so that I'm guaranteed which parts run before 
first paint and which run after.


Has anyone else made any progress on this front? Are there any 
other tools that I'm overlooking? Is there a sensible path 
forward?


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

Re: disabled non-e10s tests on trunk

[Ehsan Akhgari]

On 08/08/2017 06:51 PM, Blake Kaplan wrote:

L. David Baron  wrote:

Has there been any additional effort to deal with tests that have
been disabled under e10s?  This change means we've essentially
turned off a decent number of tests.

IIRC, the last time we talked about this, there was interest in either running
tests explicitly disabled in e10s in a non-e10s browser or doing another
e10s-style run-through and sign-off of the remaining tests to move them to
suites that won't be turned off or to verify that we don't lose test coverage
of things we care about. Felipe was going to use the scripts that we used in
the original e10s rollout to generate a new list of tests to verify.
Was this done before the tests were turned off though?  From what I read 
from the bug, it seems like the answer is no.  It seems to me that the 
above should have been a prerequisite for turning these tests off, 
especially at a time like this leading to the release of Firefox 57 when 
we should all we can to reduce the risk of the release...  Losing test 
coverage on many tests here and there, and also on Android for the tests 
that we run on desktop in lieu seems to me as potential factors to 
increase risk.  :-(

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

Re: disabled non-e10s tests on trunk

[Blake Kaplan]

L. David Baron  wrote:
> Has there been any additional effort to deal with tests that have
> been disabled under e10s?  This change means we've essentially
> turned off a decent number of tests.

IIRC, the last time we talked about this, there was interest in either running
tests explicitly disabled in e10s in a non-e10s browser or doing another
e10s-style run-through and sign-off of the remaining tests to move them to
suites that won't be turned off or to verify that we don't lose test coverage
of things we care about. Felipe was going to use the scripts that we used in
the original e10s rollout to generate a new list of tests to verify.
-- 
Blake Kaplan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[Robert O'Callahan]

On Wed, Aug 9, 2017 at 9:31 AM, Boris Zbarsky  wrote:

Something as simple as "debug something that happens during pageload" is
> currently fairly rocket science to do in e10s mode; doubly so in
> e10s-multi.  I haven't seen any concrete proposals for improving this


rr makes it fairly easy on Linux. On Mac and Windows ... yeah.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: disabled non-e10s tests on trunk

[L. David Baron]

On Tuesday 2017-08-08 14:12 -0700, jma...@mozilla.com wrote:
> As Firefox 57 is on trunk, we are shipping e10s by default.  This means that 
> our primary support is for e10s.  As part of this, there is little to no need 
> to run duplicated tests in non-e10s and e10s mode.  
> 
> In bug 1386689, we have turned them off.  There was some surprise in doing 
> this and some valid concerns expressed in comments in the bug.  Given that, I 
> thought we should bring this information to a wider audience on dev.platform 
> so more developers are aware of the change.

Has there been any additional effort to deal with tests that have
been disabled under e10s?  This change means we've essentially
turned off a decent number of tests.

Some of these tests show up in these searches:
https://searchfox.org/mozilla-central/search?q=skip-if+%3D+e10s
https://searchfox.org/mozilla-central/search?q=skip-if%28browserIsRemote
although that search isn't exhaustive, and contains some tests that
we still run under some conditions.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: disabled non-e10s tests on trunk

[Boris Zbarsky]

On 8/8/17 5:12 PM, jma...@mozilla.com wrote:

In bug 1386689, we have turned them off.  There was some surprise in doing this 
and some valid concerns expressed in comments in the bug.


Indeed.  Given how often non-e10s mode needs to get used for debugging, 
it's a little concerning to see the "yeah, it's fine if we just totally 
break non-e10s mode" comments in that bug.


Something as simple as "debug something that happens during pageload" is 
currently fairly rocket science to do in e10s mode; doubly so in 
e10s-multi.  I haven't seen any concrete proposals for improving this


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

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 8, 2017 at 5:18 PM, Ben Kelly  wrote:

> On Tue, Aug 8, 2017 at 5:12 PM,  wrote:
>
>> While we get some advantages to not running duplicated tests (faster try
>> results, less backlogs, fewer intermittent failures) there might be
>> compelling reasons to run some tests in e10s based on specific coverage.
>> With that said, I would like to say that any tests we turn on as non-e10s
>> must have a clearly marked end date- as in this is only a temporary measure
>> while we schedule work in to gain this coverage fully with e10s tests.
>>
>
> If we have an android test disabled (a lot I think), then we should
> consider continuing to run the test in non-e10s on desktop linux.  Having
> more real devices to run android tests on would probably reduce the number
> of tests that are disabled.  The emulator is extremely slow and not
> representative of real hardware.
>

Sorry to self-reply, but the best solution would of course be to move
android to a single content process e10s model.  Then we could truly remove
non-e10s.  Obviously that is probably not easy to do, though...

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

Re: disabled non-e10s tests on trunk

[Ben Kelly]

On Tue, Aug 8, 2017 at 5:12 PM,  wrote:

> As Firefox 57 is on trunk, we are shipping e10s by default.  This means
> that our primary support is for e10s.  As part of this, there is little to
> no need to run duplicated tests in non-e10s and e10s mode.
>

We still run android in non-e10s mode, right?


> In bug 1386689, we have turned them off.  There was some surprise in doing
> this and some valid concerns expressed in comments in the bug.  Given that,
> I thought we should bring this information to a wider audience on
> dev.platform so more developers are aware of the change.
>
> While we get some advantages to not running duplicated tests (faster try
> results, less backlogs, fewer intermittent failures) there might be
> compelling reasons to run some tests in e10s based on specific coverage.
> With that said, I would like to say that any tests we turn on as non-e10s
> must have a clearly marked end date- as in this is only a temporary measure
> while we schedule work in to gain this coverage fully with e10s tests.
>

If we have an android test disabled (a lot I think), then we should
consider continuing to run the test in non-e10s on desktop linux.  Having
more real devices to run android tests on would probably reduce the number
of tests that are disabled.  The emulator is extremely slow and not
representative of real hardware.

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

disabled non-e10s tests on trunk

[jmaher]

As Firefox 57 is on trunk, we are shipping e10s by default.  This means that 
our primary support is for e10s.  As part of this, there is little to no need 
to run duplicated tests in non-e10s and e10s mode.  

In bug 1386689, we have turned them off.  There was some surprise in doing this 
and some valid concerns expressed in comments in the bug.  Given that, I 
thought we should bring this information to a wider audience on dev.platform so 
more developers are aware of the change.

While we get some advantages to not running duplicated tests (faster try 
results, less backlogs, fewer intermittent failures) there might be compelling 
reasons to run some tests in e10s based on specific coverage.  With that said, 
I would like to say that any tests we turn on as non-e10s must have a clearly 
marked end date- as in this is only a temporary measure while we schedule work 
in to gain this coverage fully with e10s tests.

Also keep in mind that most if not all of the CI/scheduling/admin benefits of 
turning off the tests are already accounted for with the new stylo tests we are 
running in parallel on osx and windows.
___
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

Intent to remove CSSStyleDeclaration.getAuthoredPropertyValue()

[Bradley Werth]

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

This chrome-only API was intended to assist developer tools in
reporting the authored values for properties that are normalized after
parsing. We are removing it for four reasons:

1) Only color properties were specially handled by this API.
2) Firefox devtools doesn't call this API, and the only known add-on
that does is Firebug, which has a fallback.
3) There are APIs to do CSS lexing in JS, which provides another way
to retrieve authored values.
4) If this API is retained, the transition to Quantum Style aka
"Stylo" would require significant code changes in the Quantum Style
code and would introduce some performance inefficiency.

If you need to return authored values, you can use a mthod similar to
the one used by the Firefox devtools. There are two chrome-only APIs
in inIDOMUtils.idl:

1) getCSSLexer returns a CSS lexer that will lex some text. The lexer
is documented here:
https://dxr.mozilla.org/mozilla-central/source/dom/webidl/CSSLexer.webidl
2) getRelativeRuleLine returns the line number of a CSS rule, relative
to the 

Re: More Rust code

[Gregory Szorc]

On Mon, Aug 7, 2017 at 11:01 PM, Henri Sivonen  wrote:

> On Tue, Aug 8, 2017 at 1:12 AM, Mike Hommey  wrote:
> > Here's a bunch of data why "let's switch compilers" is not necessarily
> > easy (I happen to have gathered that recently):
>
> Thank you.
>
> > Newer versions of clang-cl might generate faster code, but they crash
> > during the build: https://bugs.llvm.org/show_bug.cgi?id=33997
>
> I'm guessing using a very new clang was what allowed Chrome to switch
> from MSVC to clang? (Chrome accepted a binary size increase on 32-bit
> Windows as a result of switching to clang.)
>

I also found references to performance hits in their issue tracker.
Specifically, it looked like process startup and new tab times regressed.
But I could find no numbers quantifying it.

We should view their decision as having to do more with using a unified and
open source toolchain [that they can patch, improve, and deploy in days
instead of months] instead of purely performance. It's a huge win for
Chrome's developers (target 1 toolchain instead of N) and it will allow
them to move faster since they're not beholden to any lagging one-off
toolchain. They still have to worry about packaging for Chromium, of
course. Hopefully this will result in faster distro packaging for newer
LLVM/Clang releases (not unlike how Rust is forcing the world to come to
terms with a toolchain that is released every 6 weeks).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treating 'data:' documents as unique, opaque origins

[Daniel Veditz]

On Tue, Aug 8, 2017 at 6:12 AM, Christoph Kerschbaumer 
wrote:

> compliant with the behavior of other browsers which all have been shipping
> that behavior for a long time.
>

No other browser has _ever_ treated data: the way we do. The spec at one
time said they should because it makes a kind of logical sense--later
 was invented to get the behavior we already had!--​but in
practice it just makes Firefox users vulnerable to web site bugs that
affect no one else.

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

Re: More Rust code

[Jeff Muizelaar]

On Mon, Aug 7, 2017 at 6:12 PM, Mike Hommey  wrote:
>   Note that the tp5n main_startup_fileio reflects the resulting size of
>   xul.dll, which also impacts the installer size:
>  32-bits   64-bits
>   MSVC (PGO):   37904383  40803170
>   clang-cl: 39537860  40561849
>   clang-cl -O2: 41976097  43338891

FWIW, https://bugs.llvm.org//show_bug.cgi?id=26299 is the metabug for
tracking improvements to x86-32 code size.

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

Re: Quantum Flow Engineering Newsletter #18

[Mike Conley]

>
> Mike Conley ported scrollbox to use smooth scrolling instead of JS driven
> scrolling .  This
> affects most importantly scrolling the tab bar, and should make it more
> smooth by removing a lot of slow code that used to run and off-loading that
> work to the compositor through CSS-based smooth scrolling!  He notes
>  on the bug
> that in order to achieve great performance some follow-ups may be needed.


Just to ensure credit is given where it's due - that was 95% Dão Gottwald's
work. I just helped push the last 5% over the line when he got focused on
getting square tabs landed. Thanks Dão!

On 4 August 2017 at 04:04, Ehsan Akhgari  wrote:

> Hi everyone,
>
> This has been a busy week.  A lot of fixes have landed, setting up the
> Firefox 57 cycle for a good start.  On the platform side, a notable change
> that will be in the upcoming Nightly is the fix for document.cookie using
> synchronous IPC.  This super popular API call slows down various web pages
> today in Firefox, and starting from tomorrow, the affected pages should
> experience a great speedup.  I have sometimes seen the slowdown caused by
> this one issue to amount to a second or more in some situations, thanks a
> lot to Amy and Josh for their hard work on this feature.  The readers of
> these newsletters know that the work on fixing this issue has gone on for a
> long time, and it's great to see it land early in the cycle.
>
> On the front-end side, more and more of the UI changes of Photon are
> landing in Nightly.  One of the overall changes that I have seen is that
> the interface is starting to feel a lot more responsive and snappy than it
> was around this time last year.  This is due to many different details.  A
> lot of work has gone into fixing rough edges in the performance of the
> existing code, some of which I have covered but most of which is under the 
> Photon
> Performance project .
> Also the new UI is built with performance in mind, so for example where
> animations are used, they use the compositor and don't run on the main
> thread.  All of the pieces of this performance puzzle are nicely coming to
> fit in together, and it is great to see that this hard work is paying off.
>
> On the Speedometer front, things are progressing with fast pace.  We have
> been fixing issues that have been on our list from the previous findings,
> which has somewhat slowed down the pace of finding new issues to work on.
> Although the SpiderMonkey team haven't waited around
>  and are
> continually finding new optimization opportunities out of further
> investigations.  There is still more work to be done there!
>
> I will now move own to acknowledge the great work of all of those who
> helped make Firefox faster last week.  I hope I am not mistakenly
> forgetting any names here!
>
>- Andrew McCreight got rid of some cycle collector overhead
> related to
>using QueryInterface to canonicalize the nsISupports pointers stored in the
>purple buffer, and similarly for pointers encountered during traversal
>of native roots 
>as well.
>- Kris Maglione added some utilities to BrowserUtils
> that should
>help our front-end devs avoid synchronous layout and style flushes.
>- Amy Chung got rid of the sync IPC messages in the cookie service
>! This was a
>substantial amount of work and should eliminate jank on a number of sites
>that get and set cookies frequently.
>- Jessica Jong made us check a boolean flag instead of doing a linear
>search looking for an attribute in order to determine whether an Element is
>required .
>- André Bargull made String.prototype.toLower/UpperCase use direct VM
>calls, and also added specialized unicode::CanLower/UpperCase overloads for
>Latin1 characters
>.  He also added
>an Ion-inline path for Reflect.getPrototypeOf()
>.  Additionally,
>he made it possible to inline UnsafeGetReservedSlot when the object is
>typed as MIRType::Value
>.  Last but not
>least, he inlined ToObject when called with MIRType::Value
>.
>- Mike Conley ported scrollbox to use smooth scrolling instead of JS
>driven scrolling .
>This affects most 

Intent to ship: Treating 'data:' documents as unique, opaque origins

[Christoph Kerschbaumer]

Hey Everyone,

we plan to change the handling of data: URLs for FF57. Rather than inheriting 
the origin of the settings object responsible for the navigation, data: URIs 
will be treated as unique, opaque origins [0]. In other words, data: URLs 
loaded inside an iframe are not same-origin with their including context 
anymore. Not only will that behavior mitigate the risk of XSS, it will also 
make Firefox spec compliant [0] and compliant with the behavior of other 
browsers which all have been shipping that behavior for a long time.

Over the past weeks we have converted hundreds of tests within our test suite 
to comply with the new data: URI inheritance model. Please note that we have 
test coverage for both worlds, the new, as well as the old behavior. By now we 
have a green TRY run for Linux, but have to do a few follow ups for other 
platforms since some of the failing tests were disabled on Linux. Anyway, 
currently this feature lives behind the pref 
|security.data_uri.unique_opaque_origin| which we plan to flip for FF57 so 
data: documents become unique, opaque, origins.

Even though we have good test coverage we are currently extending web platform 
tests to make sure behavior is consistent across browsers. We don’t think that 
adding those additional tests should hold us back from flipping the pref. 
Ideally we suggest to flip the pref rather sooner than later to eliminate 
potential issues early in Nightly.

Overall progress of the project will be tracked here [1].

Thanks,
 Christoph, Ethan, Henry, and Yoshi

[0] https://html.spec.whatwg.org/multipage/origin.html#origin 

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1324406 

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

Firefox Security Team Newsletter Q2 2017

[Paul Theriault]

I posted this to dev-security already, but received suggestions to
bring our newsletter to dev-platform as well. I believe this list is
plaintext, so instead of pasting broken content, I'll encourage you to
read the online version here:
https://wiki.mozilla.org/SecurityEngineering/Newsletter

Or below for a text-only version (but its better with links, I promise!)
Comments, suggestions and feedback all welcome.


= Firefox Security Team Newsletter Q2 17 =

Firefox 55 is out the door, so there’s time now to put together our
quarterly newsletter. In addition to the security changes which hit
release last week, there has been a number of important security
improvements land over the last quarter:
* We’ve made significant improvement of our security sandbox, with
file system restrictions shipping for Windows and macOS on beta
(Firefox 56) and Linux on nightly (Firefox 57)
* Firefox 56 has a significant speedup for the most common
cryptographic algorithm used in secure websites, AES-GCM (an official
Mozilla blog post still to come).
* We have continued the Tor Uplift work and entered the second phase
to implement browser fingerprinting resistance starting from Firefox
55.

Read on for more highlights of the important work the Firefox security
team is doing to keep our users safe online.

= Team Highlights =
== Security Engineering ==
=== Crypto Engineering ===
* Firefox 56 has a significant speedup for the most common
cryptographic algorithm used in secure websites, AES-GCM (an official
Mozilla blog post still to come).
*A regression from e10s where CORS error messages weren’t logged
properly in the console is fixed in Firefox 56.

=== Privacy and Content Security===
- We have continued the Tor Uplift work and entered the second phase
to implement browser fingerprinting resistance starting from Firefox
55.
- Converted hundreds of test cases to obey the origin inheritance
behavior for data: URIs in support of an important spec change. Intent
to ship in Firefox 57.
- Made significant performance improvement on security components in
support of Quantum Flow project.

=== Content Isolation ===*
- Shipping file system user token restriction for Windows content in 56
- Shipping 3rd party legacy extension blocking for Windows content in 56
- Shipping file system read access restrictions for OSX content in 56
- Linux content sandboxing (“level 2”: write restrictions, some
syscalls, probably escapable) released in 54. Work to enable read
restrictions (enabled at time of writing in Nightly 56 targeting 57
rollout) also completed.

== Operations Security ==
- The security audit of Firefox Accounts performed by Cure53 last year
was publicly released.
- We completed the implementation of API Scanning with ZAP, to
automate vulnerability scanning of our services by leveraging OpenAPI
definitions.
- The signing of add-ons has been ported to the Autograph service,
where support for SHA-256 PKCS7 signatures will be added.
- TLS Observatory accelerated the loading of CT logs, with currently
~70M certificates recorded. It should reach 200M in Q3.

== Security Assurance ==
- New team created to focus on Firefox security assurance
- Working on adding security checks to our build tools to help our
developer avoid landing security bugs. First outcome of this project
was landing an ESLint plugin to prevent the unsafe usage of eval,
innerHTML etc. in Firefox.

== Cross-Team Initiatives ==
- The TLS Canary project has seen the feature release 3.1. NSS team is
working on treeherder integration.
- Common CA Database (CCADB) access has been granted to the rest of
the CAs in Microsoft’s root store (those that are also in Mozilla’s
root store already had CA Community licenses/access).

== Security Blog Posts & Presentations =
https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/
(Kathleen)
https://blog.mozilla.org/security/2017/05/11/relaunching-web-bug-bounty-program/
(April from Enterprise Infosec)
https://blog.mozilla.org/security/2017/06/28/analysis-alexa-top-1m-sites/
(April from Enterprise Infosec)
https://blog.mozilla.org/security/2017/07/18/web-service-audits-firefox-accounts/
(Greg from Services Security)
Francois Marier gave a talk on security and privacy settings for
Firefox power users at LinuxFest Northwest.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Finalizer for WebIDL object backed by JS impl of an XPCOM interface

[Henri Sivonen]

What's the correct way to take an action right before a JS-implemented
XPCOM object that acts as the implementation for a WebIDL interface
gets garbage collected?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Changing .idl files

[Henri Sivonen]

On Tue, Aug 8, 2017 at 6:17 AM, Kris Maglione  wrote:
> On nightlies and
> in unbranded builds, it will still be possible to enable them by flipping a
> pref, but they will be completely unsupported.
>
> Yes, that means that some users and developers will continue to use them,
> and continue to get upset when they break

Why is it worthwhile to keep a configuration that will continue to
make people upset? Does there exist a known set of legacy extensions
that 1) do something that WebExtensions can't yet do and that 2) are
limited to using interfaces that we don't want to remove or refactor
ASAP?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More Rust code

[Henri Sivonen]

On Tue, Aug 8, 2017 at 1:12 AM, Mike Hommey  wrote:
> Here's a bunch of data why "let's switch compilers" is not necessarily
> easy (I happen to have gathered that recently):

Thank you.

> Newer versions of clang-cl might generate faster code, but they crash
> during the build: https://bugs.llvm.org/show_bug.cgi?id=33997

I'm guessing using a very new clang was what allowed Chrome to switch
from MSVC to clang? (Chrome accepted a binary size increase on 32-bit
Windows as a result of switching to clang.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform