Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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,

Phabricator and confidential reviews

2017-08-08 Thread Mark Côté
(Cross-posted to mozilla.tools) Hi, I have an update and a request for comments regarding Phabricator and confidential reviews. We've completed the functionality around limiting access to Differential revisions (i.e. code reviews) that are tied to confidential bugs. To recap the original

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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,

disabled non-e10s tests on trunk

2017-08-08 Thread 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

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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

Re: disabled non-e10s tests on trunk

2017-08-08 Thread Blake Kaplan
Boris Zbarsky wrote: > 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. > Something as simple as "debug something that happens during

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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

Figuring out and controlling what tasks run before first paint

2017-08-08 Thread 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

Re: Changing .idl files

2017-08-08 Thread 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

Re: More Rust code

2017-08-08 Thread 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:

Re: More Rust code

2017-08-08 Thread 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):

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

2017-08-08 Thread 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

Re: disabled non-e10s tests on trunk

2017-08-08 Thread 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).

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

2017-08-08 Thread 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

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

2017-08-08 Thread zbraniecki
During FxOS days we spent a lot of time designing the "bootstrapping" stages of the app/system. We came up with 5 stages: 1) navigationLoaded 2) navigationInteractive 3) visuallyLoaded 4) contentInteractive 5) fullyLoaded

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

2017-08-08 Thread 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

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

2017-08-08 Thread 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

Firefox Security Team Newsletter Q2 2017

2017-08-08 Thread 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

Re: Quantum Flow Engineering Newsletter #18

2017-08-08 Thread 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

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

2017-08-08 Thread 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

Intent to remove CSSStyleDeclaration.getAuthoredPropertyValue()

2017-08-08 Thread 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)

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

2017-08-08 Thread 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

Re: More Rust code

2017-08-08 Thread 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

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

2017-08-08 Thread 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

Re: More Rust code

2017-08-08 Thread 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. > > >