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

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 d

Firefox Security Team Newsletter Q2 2017

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 be

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

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 the

Re: Quantum Flow Engineering Newsletter #18

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

Re: More Rust code

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-

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

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

Re: More Rust code

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

Intent to remove CSSStyleDeclaration.getAuthoredPropertyValue()

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

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 aga

disabled non-e10s tests on trunk

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 som

Re: disabled non-e10s tests on trunk

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, righ

Re: disabled non-e10s tests on trunk

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

Re: disabled non-e10s tests on trunk

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 "y

Re: disabled non-e10s tests on trunk

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, w

Re: disabled non-e10s tests on trunk

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

Re: disabled non-e10s tests on trunk

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 pageload" is > current

Re: disabled non-e10s tests on trunk

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 disable

Re: disabled non-e10s tests on trunk

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 i

Phabricator and confidential reviews

(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 plan

Figuring out and controlling what tasks run before first paint

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 pai

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

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

Re: More Rust code

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

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

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 mani

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

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 https://hacks.mozilla.org/2015/06/performance-testing-firefox-os-with-rap

Re: disabled non-e10s tests on trunk

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

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 c

Re: Phabricator and confidential reviews

On 08/09/2017 12:30 AM, Mark Côté wrote: Hi, I have an update and a request for comments regarding Phabricator and confidential reviews. First of all, thanks for considering confidential bugs as part of this process. This was my main reason for not using moz-review. We've completed the fu