Re: Quantum Flow Engineering Newsletter #22

> - We found out that MediaStreamGraphStableStateRunnable is #20 on this > list, which was surprising as this runnable is only supposed to be used for > WebRTC and WebAudio, neither being extremely popular features on the Web. > Randell Jesup found out that there is a bug >

Rust bindings to SpiderMonkey on inbound

(cc dev-servo, dev-platfrom; reply to js-engine-internals) Hello everyone! The Rust bindings to SpiderMonkey that Servo uses just landed in mozilla-inbound[0]! You can monitor their test results on taskcluster as the `SM-tc[tier-2](rust)` job. If any of your patches break these tests, please pin

Rust logging with e10s

If you've used RUST_LOG to enable logging for Rust modules, but were hoping you could filter down to child processes only, bug 1390736 now allows you to use RUST_LOG_CHILD to target them. This has been helpful for several of us working on Stylo. To use, just replace RUST_LOG with RUST_LOG_CHILD an

Re: Web Platform Tests in Headless Mode

(One addition you may want to make is passing the --no-pause-after-test option to ./mach web-platform-tests. The default behavior is to pause so that you can see the test output in the Firefox window; in headless mode this isn't so helpful. Thanks :bz!) -Michael On 9/1/2017 14:27, Michael Smi

Re: Stylesheet wait timeout?

On Fri, Sep 01, 2017 at 11:32:43PM +0200, Anthony Ricaud wrote: I have no idea if this is feasible but could we prevent extensions from performing synchronous layout flushes before layout has started? If this is possible, extensions that need to perform them could require a new permission? It

Re: Stylesheet wait timeout?

I have no idea if this is feasible but could we prevent extensions from performing synchronous layout flushes before layout has started? If this is possible, extensions that need to perform them could require a new permission? Another alternative, can we prevent extensions from injecting content

Web Platform Tests in Headless Mode

Hi everyone, This is a quick note to announce that the Web Platform Tests are headless mode compatible. (I say "announce", but this has really been the case since https://bugzil.la/1373739 was resolved.) This means that you can run one or more web platform tests without having actual Firefox

Re: Stylesheet wait timeout?

On 9/1/17 10:15 AM, Dustin Mitchell wrote: I can narrow that bisection down to two sets: [test-pilot] and []. So test-pilot is causing the flash of unstyled content in your case? I assume this is the addon at https://testpilot.firefox.com/ ? What pages are you seeing the flash of unstyled c

Re: Eiminating nsIDOM* interfaces and brand checks

On 9/1/17 4:54 PM, Kris Maglione wrote: The other potential issue is that the `instanceof Ci.nsIDOM...` checks tend to appear in places like JSMs, where we don't have direct access to constructors for DOM interfaces by default. Right, if we used one of the things that use constructors, we'd h

Re: Stylesheet wait timeout?

FWIW I filed https://bugzil.la/1396097 for adding a console warning which would have warned about this specific case. On 09/01/2017 12:37 PM, Boris Zbarsky wrote: On 8/31/17 3:00 PM, Michael Froman wrote: If I disable Ghostery, it no long appears to happen for me. YMMV. Michael, Thank you

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 01, 2017 at 04:43:31PM -0400, Ehsan Akhgari wrote: On 09/01/2017 01:18 PM, Boris Zbarsky wrote: That has the unfortunate side-effect of allocating a new JS string for every call, but we can probably optimize it if it becomes necessary. We could add a hasClassName if we wanted. I

Re: Eiminating nsIDOM* interfaces and brand checks

On 09/01/2017 01:18 PM, Boris Zbarsky wrote: That has the unfortunate side-effect of allocating a new JS string for every call, but we can probably optimize it if it becomes necessary. We could add a hasClassName if we wanted. I'm kind of missing what's better about this compared to the other

Intent to unship: :-moz-empty-except-children-with-localname, :-moz-devtools-highlighted, and :-moz-styleeditor-transitioning from content documents.

Pretty much in the same spirit as my previous mail, I intend to unship access to these pseudo-classes in content documents. The idea would be, similarly, to do that for FF 58. The reasoning behind is that there's no spec for them, and they're implementation details, basically. In particular: *

Intent to unship: :-moz-system-metric pseudo-class and media queries in content pages.

Hi dev-platform@, I'd like to unship access to the :-moz-system-metric pseudo-class, and the system metric media queries, from content pages. I just filed for that. They're not in any spec, and they seem unused (I can't find anything non-mozi

PSA: MOZ_TRY() now works with nsresult values and in nsresult-valued functions

As of the landing of bug 1366511, it's now possible to use MOZ_TRY with and from functions that return nsresult values. This means that, among other things, it's now easy to use mozilla::Result from XPCOM methods, and vice versa, as long as the Result error type is nsresult: #include "mozil

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 01, 2017 at 01:18:12PM -0400, Boris Zbarsky wrote: That has the unfortunate side-effect of allocating a new JS string for every call, but we can probably optimize it if it becomes necessary. We could add a hasClassName if we wanted. That's an interesting idea. It would also remov

Re: Eiminating nsIDOM* interfaces and brand checks

On 9/1/17 1:06 PM, Kris Maglione wrote:  if (ChromeUtils.getClassName(element) == "HTMLEmbedElement") Ah, that works. Though I think spidermonkey wants to maybe get rid of classnames and on the flip side it's not clear whether HTMLEmbedElement.prototype will end up with the same classna

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 1, 2017 at 9:59 AM, Botond Ballo wrote: > On Fri, Sep 1, 2017 at 12:11 PM, Ehsan Akhgari > wrote: > > How about this slight variation: > > > > HTMLEmbedElement.isInstanceOf(obj) > > > > instead of "is"? > > Isn't that backwards, though? HTMLEmbedElement isn't an instance of > 'obj',

Re: Stylesheet wait timeout?

On Fri, Sep 01, 2017 at 10:52:30AM -0400, Ehsan Akhgari wrote: On 09/01/2017 09:54 AM, Boris Zbarsky wrote: On 9/1/17 7:02 AM, Gervase Markham wrote: Restarting with no extensions causes my browser to feel a whole lot faster (I'd love to know why that is, but that's a separate issue!) Worth t

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 01, 2017 at 11:01:51AM -0400, Boris Zbarsky wrote: Now that we control all the code that can attempt to touch Components.interfaces.nsIDOM*, we can try to get rid of these interfaces and their corresponding bloat. The main issue is that we have consumers that use these for testing

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 1, 2017 at 12:11 PM, Ehsan Akhgari wrote: > How about this slight variation: > > HTMLEmbedElement.isInstanceOf(obj) > > instead of "is"? Isn't that backwards, though? HTMLEmbedElement isn't an instance of 'obj', 'obj' is an instance of HTMLEmbedElement :) Cheers, Botond _

Re: Eiminating nsIDOM* interfaces and brand checks

Accidentally sent this off-list. On Fri, Sep 1, 2017 at 12:14 PM, Michael Layzell wrote: > I personally like the style of (2) the most, The isWhatever style methods > are too verbose, and I don't think that adding more code which depends on > behavior we might want to remove from Firefox is a go

Re: Stylesheet wait timeout?

On 8/31/17 3:00 PM, Michael Froman wrote: If I disable Ghostery, it no long appears to happen for me. YMMV. Michael, Thank you. So with Ghostery installed, I managed to reproduce a flash of unstyled content when doing a force-reload of https://github.com/servo/servo That's because Ghoste

Re: Eiminating nsIDOM* interfaces and brand checks

On 09/01/2017 11:01 AM, Boris Zbarsky wrote: Anyway, we need a replacement. Some possible options: 1) Use "obj instanceof Whatever". The problem is that we'd like to maybe kill off the cross-global instanceof behavior we have now for DOM constructors. 2) Introduce chromeonly "is" methods

Eiminating nsIDOM* interfaces and brand checks

Now that we control all the code that can attempt to touch Components.interfaces.nsIDOM*, we can try to get rid of these interfaces and their corresponding bloat. The main issue is that we have consumers that use these for testing what sort of object we have, like so: if (obj instanceof Ci

Re: Stylesheet wait timeout?

On 09/01/2017 09:54 AM, Boris Zbarsky wrote: On 9/1/17 7:02 AM, Gervase Markham wrote: Restarting with no extensions causes my browser to feel a whole lot faster (I'd love to know why that is, but that's a separate issue!) Worth trying to bisect on the extensions to figure this out... Or alter

Re: Stylesheet wait timeout?

I can narrow that bisection down to two sets: [test-pilot] and []. Dustin 2017-09-01 9:54 GMT-04:00 Boris Zbarsky : > On 9/1/17 7:02 AM, Gervase Markham wrote: >> >> Restarting with no extensions causes my browser to feel a whole lot >> faster (I'd love to know why that is, but that's a separate

Re: Quantum Flow Engineering Newsletter #22

On Fri, Sep 1, 2017 at 10:06 AM, Ben Kelly wrote: > On Fri, Sep 1, 2017 at 1:59 AM, Ehsan Akhgari > wrote: > >>- Mike Conley made it so that background tabs are “warmed up” when >>hovering the mouse cursor over them >>. This shoul

Re: Quantum Flow Engineering Newsletter #22

On Fri, Sep 1, 2017 at 1:59 AM, Ehsan Akhgari wrote: >- Mike Conley made it so that background tabs are “warmed up” when >hovering the mouse cursor over them >. This should >improve tab switching perceived performance. > I jus

Re: Stylesheet wait timeout?

On 9/1/17 7:02 AM, Gervase Markham wrote: Restarting with no extensions causes my browser to feel a whole lot faster (I'd love to know why that is, but that's a separate issue!) Worth trying to bisect on the extensions to figure this out... but I can't reproduce the FOUC in a few minutes of t

Re: New minimum Rust version policy for Firefox

There was a bit of discussion on the PR I submitted yesterday: https://github.com/servo/webrender/pull/1644#discussion_r136424367 - we decided to just manually bump it once in a while instead of making it track `stable`. On Thu, Aug 31, 2017 at 5:54 PM, Mike Hommey wrote: > On Thu, Aug 31, 2017 a

Testing & "Intent to Ship"

Looking back over recent "Intent to Ship" emails for web platform exposed features, I notice that only half make any mention of accompanying tests. Since cross-browser tests are one of the main ways we prevent today's exciting new feature being tomorrow's site-breaking compat nightmare, I'd l

PSA: symbol server now available via https

Just an FYI, yesterday the symbol server (symbols.mozilla.org) was moved to a different server backend[1], and as a result it's now also available via https. It should continue to work seamlessly at the existing URL, but you can update your symbol server paths to https://symbols.mozilla.org/ if you

Re: Stylesheet wait timeout?

On 31/08/17 19:08, Boris Zbarsky wrote: > The symptoms you observe sound like (A) is happening, possible from an > extension or our browser UI...  If you have a link to a specific url > that reproduces for you, especially in a clean profile, that would be > pretty useful.  This is usually pretty si

Re: Stylesheet wait timeout?

On 31/08/17 20:00, Michael Froman wrote: > I’ve seen this behavior too on OSX. I did a restart with all add-ons > disabled and could not reproduce. Restarted with all add-ons on, and > can reproduce. I narrowed it down to Ghostery. If I disable > Ghostery, it no long appears to happen for me.

Re: Stylesheet wait timeout?

On 31/08/17 18:45, Chris Peterson wrote: > 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". about:support says "Stylo: true (enabled by default)". Gerv _