Changing remote type of xpcshell Content processes from "" to "web"

Right now if you have an e10s xpcshell test, the remote type of the resulting child (content) process will be NO_DEFAULT_TYPE="". This is not a real type, this is not a type you should ever see in Firefox. In https://bugzilla.mozilla.org/show_bug.cgi?id=1395827 I propose changing the type to D

Quantum Flow Engineering Newsletter #22

Hi everyone, With around three weeks left in the development cycle for Firefox 57, everyone seems to be busy getting the last fixes in to shape up this long-awaited release. On the Quantum Flow project, we have kept up with the triage of the incoming bug reports that are tagged as [qf], and as we

Proposal: Unified Bootstrap Stages for Gecko

Gecko has a pretty substantial number of metrics used for measuring startup performance. We have probes in Telemetry [0], StartupTimeline [1], various uses of MozAfterPaint, both in talos tests [2] and in production code [3][4]. We also have first paint in compositor [5], before-first-paint [6],

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 31/08/17 21:22, Jack Moffitt wrote: Is there another alternative besides CDP you'd like to propose? I don't have an alternate proposal, and I feel like I must have been unclear at some point. I'm not saying "this is bad, period". I'm certainly not saying "this is bad because it isn't WebD

Re: New minimum Rust version policy for Firefox

On Thu, Aug 31, 2017 at 10:27:55AM -0500, Jack Moffitt wrote: > Specifically for webrender (and anything else under the servo org on > GitHub), you can just file a bug and assign to edunham and we'll fix > that up. > > jack. Note that for webrender specifically, it used to build against stable, b

Re: Implementing a Chrome DevTools Protocol server in Firefox

Sorry for the premature send. The complete message should read: The primary goals here are not related to automation and testing. - We want to migrate the Devtools console and the JS debugger to the CDP, to replace an unpopular protocol with a more widely-used one. - Servo wants its devtools ser

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Thursday, August 31, 2017 at 1:10:30 PM UTC-7, James Graham wrote: > If people are starting to standardise not just the protocol but also the > semantics of CDP, that's great. But people tend to vastly underestimate > how long standardisation will take, and overestimate the resources that > t

Re: Implementing a Chrome DevTools Protocol server in Firefox

Certain bits of the original post are getting more emphasis than I had anticipated. Let me try to clarify why we in Devtools want this change or something like it. The primary goals here are not related to automation and testing. They are: - to allow Devtools to migrate the console and the JS

Re: Implementing a Chrome DevTools Protocol server in Firefox

> I entirely agree that the current Firefox protocol is also proprietary. > However I also assumed that it's considered an internal implementation > detail rather than something we would expect people to interoperate with. If > that wasn't the case then I apologise: I should have complained earlier

Re: Implementing a Chrome DevTools Protocol server in Firefox

Google has indicated a willingness to participate in standardizing the protocol. If we switch from a devtools protocol used only by us to a tooling protocol used by the rest of the industry, that is strictly an improvement over the status quo, even if our implementation deviates from the others' t

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Thursday, August 31, 2017 at 2:51:41 AM UTC-7, James Graham wrote: > On 31/08/17 02:14, Michael Smith wrote: > > On 8/30/2017 15:56, David Burns wrote: > > > Do we know if the other vendors would see value in having this > > spec'ed properly so that we have true interop here? Reverse engineeri

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 31/08/17 19:42, Jim Blandy wrote: Some possibly missing context: Mozilla Devtools wants to see this implemented for our own use. After much discussion last summer in London, the Firefox Devtools team decided to adopt the Chrome Debugging Protocol for the console and the JavaScript debugger.

Re: Stylesheet wait timeout?

On 8/31/17 3:27 PM, Jet Villegas wrote: FWIW, reverting the fix for bug 1283302 (fixed in FF53) fixes this issue. Before that fix, we would wait up to 250ms before painting To be clear, this is 250ms _after_ the layout-starting I described in my previous post. The general point remains: if y

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Thu, Aug 31, 2017 at 2:50 AM, James Graham wrote: > In general it seems unfortunate if we are deciding to implement a > proprietary protocol rather than opting to either extend something that is > already a standard (e.g. WebDriver) or perform standardisation work > alongside the implementatio

Re: Stylesheet wait timeout?

FWIW, reverting the fix for bug 1283302 (fixed in FF53) fixes this issue. Before that fix, we would wait up to 250ms before painting, now we wait for 5ms. You may be running into the intersection of that change, plus several performance fixes that make us paint much faster in FF57. When we fixed 12

Re: Stylesheet wait timeout?

On Thu, Aug 31, 2017 at 02:00:49PM -0500, 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

Re: Stylesheet wait timeout?

I've seen it a few times now since this thread began. I had Ghostery installed but removed it a few days ago. I only have whimsy (disabled) and test pilot installed. Dustin 2017-08-31 15:00 GMT-04:00 Michael Froman : > >> On Aug 31, 2017, at 1:08 PM, Boris Zbarsky wrote: >> >> The symptoms yo

Re: Stylesheet wait timeout?

> On Aug 31, 2017, at 1:08 PM, 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

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 8/30/17 6:14 PM, Michael Smith wrote: On 8/30/2017 18:04, Josh Matthews wrote: > One clarification - while all of the Servo codebase exists in mozilla-central/servo/, only the dependencies used by Stylo are vendored in third-party/rust. That means that neither hyper nor tokio are vendored

Re: Implementing a Chrome DevTools Protocol server in Firefox

Some possibly missing context: Mozilla Devtools wants to see this implemented for our own use. After much discussion last summer in London, the Firefox Devtools team decided to adopt the Chrome Debugging Protocol for the console and the JavaScript debugger. (The cases for converting the other tools

Re: Incoming JS module (JSM) / component loader changes

To clarify, this is about XPConnect JS modules (loaded by Cu.import[1]) and components, not ES6 modules[2], which already work this way. [1]: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Using [2]: https://hacks.mozilla.org/2015/08/es6-in-depth-modules/ On Thu, Aug 3

Re: Stylesheet wait timeout?

On 8/31/17 8:00 PM, Chris Peterson wrote: Maybe this is stylesheet delay is related to Context Driven Priority (CDP) project that changes how network requests are prioritized? https://bugzilla.mozilla.org/show_bug.cgi?id=CDP CSS preload requests (made by html parser when is hit) are left as

Re: Implementing a Chrome DevTools Protocol server in Firefox

Definitely, yes. As Michael said, some core subset of the protocol is already a de-facto standard. The process of actual specification, with committees and processes and imprimaturs and all that, is getting started, with interest from several major players, including Microsoft and Google. On Wed,

Incoming JS module (JSM) / component loader changes

A quick heads-up on some incoming changes to the JS component loader that may affect some existing JSM or JS component code: 1) As of bug 1394556[1], all JS module and component scripts are automatically compiled in strict mode[2]. While I fixed all of the resulting issues that showed up in au

Re: Stylesheet wait timeout?

On 31/08/2017 19: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". I’ve also seen many more "flashes of unstyled content" than usual la

Re: Stylesheet wait timeout?

On 8/31/17 1:24 PM, Gervase Markham wrote: Have we changed the timeout recently regarding how long Firefox waits for a stylesheet before rendering the page? We do not have such a timeout at all. Our wait is fairly deterministic. We start layout as soon as: A) Script requests layout informa

Re: Stylesheet wait timeout?

Maybe this is stylesheet delay is related to Context Driven Priority (CDP) project that changes how network requests are prioritized? https://bugzilla.mozilla.org/show_bug.cgi?id=CDP On 2017-08-31 10:46 AM, Dustin Mitchell wrote: I've been seeing this, too, often on github pages. I do not ha

Re: Stylesheet wait timeout?

I've been seeing this, too, often on github pages. I do not have stylo enabled per about:support ("false (disabled by default)"). Dustin 2017-08-31 13:45 GMT-04:00 Chris Peterson : > Gerv, do you have Stylo enabled? Even if you did not flip the pref > (layout.css.servo.enabled), you might be in

Re: Stylesheet wait timeout?

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". On 2017-08-31 10:24 AM, Gervase Markham wrote: On 18/08/17 12:11, Gervase Markham wrote: Whereas what I me

Re: Stylesheet wait timeout?

On 18/08/17 12:11, Gervase Markham wrote: Whereas what I meant to say was: Have we changed the timeout recently regarding how long Firefox waits for a stylesheet before rendering the page? In the past few weeks I've seen many more instances of a page loading unstyled, then re-laying out a second

Re: Coding style: Argument alignment

On 08/30/2017 09:03 PM, Eric Rahm wrote: Okay sounds like there's agreement on a). Indeed. I have edited the Style Guide to reflect this. Thanks everyone! -e On Tue, Aug 29, 2017 at 11:40 PM, Martin Thomson > wrote: On Wed, Aug 30, 2017 at 12:07 PM, L. David B

Firefox Nightly - now with twice as many builds a day!

Bug 1349227[1] landed a few days ago, which means we are now doing "nightly" builds twice a day at 1000 and 2200 UTC. The purpose of doing multiple nightlies is to get fixes out to users in Europe, Africa and Asia sooner. We have some concerns about possible impact to the build infrastructure, so

Re: New minimum Rust version policy for Firefox

Specifically for webrender (and anything else under the servo org on GitHub), you can just file a bug and assign to edunham and we'll fix that up. jack. On Thu, Aug 31, 2017 at 10:25 AM, Kartikaya Gupta wrote: > Do we have a policy on CI coverage for vendored rust libraries? I'm > concerned for

Re: New minimum Rust version policy for Firefox

Do we have a policy on CI coverage for vendored rust libraries? I'm concerned for example that we depend on a number of third-party rust libraries that don't do CI builds against rust stable and so it's possible they might break. I discovered that webrender CI for example is currently only building

Re: ./mach try fuzzy: A Try Syntax Alternative

+to...@lists.mozilla.org There have been a bunch of new features added here I'd like to highlight: - --artifact/--no-artifact: This works similarly to try syntax. If a local build with artifact builds is detected, --artifact will be used automatically. Unlike try syntax, this will change

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Wed, Aug 30, 2017, at 08:20 PM, Eric Rescorla wrote: > I assume this is going to involve TLS (generally this is a requirement > for > H2). In Firefox, this is done with NSS. Does Tokio/Hyper cleanly separate > out the TLS stack so that you can do that? This was mostly answered in another reply,

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 31/08/17 02:14, Michael Smith wrote: On 8/30/2017 15:56, David Burns wrote: > Do we know if the other vendors would see value in having this spec'ed properly so that we have true interop here? Reverse engineering seems like a "fun" project but what stops people from breaking stuff without

Enable coalescing mousemove in Firefox Nightly builds

We plan to enable coalescing mousemove in Firefox Nightly builds within the next few days. With this enabled, we will coalesce all mousemove events to one per refresh driver tick. It is to reduce the cost of processing unnecessary mousemove events that have no visual effect to the users. Relate