Quantum Flow Engineering Newsletter #2

Hi everyone, This past week was another busy week chasing down performance issues in Firefox. We managed to knock out a few issues, get closer to close out a couple of really high impact ones, and are making good progress on starting to get performance data from telemetry which will hopefully

Re: Tracking bug for removals after XPCOM extensions are no more?

On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote: What's the current outlook on letting chrome JS read ArrayBuffers as opposed to JS strings where the high 8 bits are zero and the low 8 bits are the byte values from XPCOM streams? (Or letting chrome JS access things that are

Re: Tracking bug for removals after XPCOM extensions are no more?

On Thu, Mar 16, 2017 at 11:23 AM, R Kent James wrote: > On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: > >> after Firefox 57 when >> Webextensions are the only extensions, if our product no longer needs some >> functionality (and it's "API"), let's remove it. Quickly and

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: after Firefox 57 when Webextensions are the only extensions, if our product no longer needs some functionality (and it's "API"), let's remove it. Quickly and ruthlessly. We need to actively work to maintain less code. I'm struggling to have a big

Re: Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

On 16.03.17 09:08, Boris Zbarsky wrote: We should try marking nsIOutputStream builtinclass on trunk right now. As far as I can tell, this should just work. No adverse effects on Thunderbird, I hope: https://dxr.mozilla.org/comm-central/search?q=nsIOutputStream=false As far as I can see we

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/13/17 11:36 AM, Steve Fink wrote: There's a whitelist of "safe" things that we assume will never be overridden. But now I can remove everything that treats nsISupports specially. Things can still be implemented in chrome JS via XPCWrappedJS, right? Assuming the analysis will consider all

Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

Do we need to keep caring about https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM extensions are no more? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to ship: IntersectionObserver API

> > 1) Is there devtools support for this (e.g. to be able to see what > intersection observers are registered where)? If not, are there at least > bugs tracking it? I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1347849 for this. MutationObserver would be a good one to add support for

Re: Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

On 3/16/17 3:35 AM, Henri Sivonen wrote: Do we need to keep caring about https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM extensions are no more? A first glance, no. We should try marking nsIOutputStream builtinclass on trunk right now. As far as I can tell, this should just

Re: Intent to ship: IntersectionObserver API

On Wed, Mar 15, 2017 at 7:38 PM, Boris Zbarsky wrote: > On 3/15/17 1:32 PM, Tobias Schneider wrote: >> 2.3) Platform tests are in the process of being upstreamed by Google ( >> https://github.com/w3c/web-platform-tests/pull/4384). > > That seems to be in limbo for well over a

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

I apologize for the delays in bug 1246615. It fell off my radar with a series of trips. I've set up a meeting tomorrow to at least identify who is responsible for this decision, because it's not exactly me. I analyzed some data in the bug which I'll repeat here. Here is an analysis of the

Re: Editing vendored crates

On 27/02/17 19:47, Simon Sapin wrote: On 27/02/17 19:30, Henri Sivonen wrote: On Mon, Feb 27, 2017 at 8:00 PM, Bobby Holley wrote: FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a crate. Thanks, but what I'm trying to figure out isn't whose

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 11:07 AM, Ehsan Akhgari wrote: > > Now, on to the credits section. I’d like to take a moment to recognize > the work of the following individuals who have helped with various aspects > of the Quantum Flow project. Thank you very much for your

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 11:07:19AM -0400, Ehsan Akhgari wrote: This is why a while ago we decided to disallow the addition of new synchronous IPC messages by default (bug 1336919) to avoid programmers adding more issues of this nature to the code base. Are there any plans to do something

Switching to async/await from Task.jsm/yield

For a long time now we've been writing JS code that waits for promises using Task.jsm and generator functions. Recently though the JS team added support for the JS standard way of doing this, async/await: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

FYI: git-cinnabar and a "Intermittent IndexError: tuple index out of range" error

If you are seeing this error when you try to do |git mozreview push|, update your version-control-tools. Then you'll see a different error. Work related to that is being looked at in https://bugzilla.mozilla.org/show_bug.cgi?id=1338530 Andrew ___

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote: Writing code in standard JS is always better for the web, makes it easier to onboard new engineers and allows for better support in developer tools. So I'd like to propose that we switch to the standard way of writing these functions

Re: Switching to async/await from Task.jsm/yield

For modules that have already converted, is there any performance change (good or bad) between async / await vs. Task? - Ryan On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione wrote: > On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote: > >> Writing code in

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote: For modules that have already converted, is there any performance change (good or bad) between async / await vs. Task? I haven't noticed any differences either way, but I also haven't done any explicit profiling. There's

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 4:27 PM, Kris Maglione wrote: > On Thu, Mar 16, 2017 at 11:07:19AM -0400, Ehsan Akhgari wrote: > >> This is why a while ago we decided to disallow the addition of new >> synchronous IPC messages by default (bug 1336919) to avoid programmers >>

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

It would be useful to know if most of those users are just downgrading the previous version (N-1 for release, N-7 for ESR), and how quickly they return to a current release (assuming they do!). This would help inform to what degree we need to support (and test!) the myriad combinations of

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 09:08:24PM -0400, Michael Layzell wrote: Can we pass async functions everywhere where we use `add_task` in tests already? If we can't, is there a tracking bug for converting all of the test systems to support it? Yes, add_task accepts any function which returns a

Re: Tracking bug for removals after XPCOM extensions are no more?

On Thu, Mar 16, 2017 at 7:34 AM, Boris Zbarsky wrote: > On 3/15/17 5:35 PM, Henri Sivonen wrote: >> >> What's the current outlook on letting chrome JS read ArrayBuffers as >> opposed to JS strings where the high 8 bits are zero and the low 8 >> bits are the byte values from

Re: windows build anti-virus exclusion list?

On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly wrote: > - mozilla-build install dir > - visual studio install dir > - /users/bkelly/appdada/local/temp > - /users/bkelly (because temp dir was not enough) > FWIW, adding all these extra exclusions dropped my build time

Re: windows build anti-virus exclusion list?

Depending on your AV, if you don't exempt mozilla-central some of our tests will get quarantined and you won't be able to build at all. - mhoye On Mar 16, 2017 20:34, "Ben Kelly" wrote: On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly wrote: > -

windows build anti-virus exclusion list?

Hi all, I'm trying to configure my new windows build machine and noticed that builds were still somewhat slow. I did: 1) Put it in high performance power profile 2) Made sure my mozilla-central dir was not being indexed for search 3) Excluded my mozilla-central directory from windows defender

Re: windows build anti-virus exclusion list?

Try using Sysinternals Process Monitor to see what files MsMpEng.exe is reading. On Fri, Mar 17, 2017, at 04:26 PM, Ben Kelly wrote: > Hi all, > > I'm trying to configure my new windows build machine and noticed that > builds were still somewhat slow. I did: > > 1) Put it in high performance

Re: windows build anti-virus exclusion list?

On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye wrote: > Depending on your AV, if you don't exempt mozilla-central some of our > tests will get quarantined and you won't be able to build at all. > I guess I was hoping someone familiar with our build might know the answer. :-)

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly wrote: > On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye wrote: > > Depending on your AV, if you don't exempt mozilla-central some of our >> tests will get quarantined and you won't be able to build at all. >> > >

Re: windows build anti-virus exclusion list?

On 2017-03-17 12:06 AM, Ben Kelly wrote: On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly > wrote: On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye > wrote: Depending on your AV, if you