date:20170901


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 content on?

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 have to 
import them into the JSM scope to do these checks.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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.  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 Ghostery does a .clientHeight get with this stack:

0 setBoxHeights() 
["moz-extension://8ecb1f2d-060f-ce44-96ed-44895f11ca4b/dist/purplebox.js":128]
1 handleMessages(request = [object Object], sender = [object Object]) 
["moz-extension://8ecb1f2d-060f-ce44-96ed-44895f11ca4b/dist/purplebox.js":448]


(the rest is less important).

I reported this issue to them (copy/paste of my report below) through 
the form at https://ghostery.zendesk.com/hc/en-us/requests/new but if 
someone has better contact info that might be nice.


-Boris

Report I sent:

STEPS TO REPRODUCE:

1)  Install Ghostery in Firefox.
2)  Load https://github.com/servo/servo/
3)  Force-reload a few times.

ACTUAL RESULTS: Eventually you get a flash of unstyled content: 
content being rendered before the stylesheets are loaded.


EXPECTED RESULTS: No flashes of unstyled content.

DETAILS: The flash of unstyled content is due to Ghostery forcing a 
layout before the stylesheets are loaded.  This happens when the 
setBoxHeights() function, in purplebox.js is called from 
handleMessages(), which is handling the 'createBox' message.


setBoxHeights does this:

windowHeight = doc.documentElement.clientHeight * 0.85 - 35;

which forces layout of "doc" which in this case is the webpage being 
loaded.  If all you want is the height of the window that document is 
in, possibly with some adjustments, you could use 
`doc.defaultView.innerHeight`, or `win.innerHeight` if "win" is the 
window for "doc".  The innerHeight getter doesn't need to perform 
layout within the window itself, and won't cause this problem.


It might also be possible to not do 'createBox' until layout has 
started on the page.  I'm not sure that point in time is exposed to 
extensions at the moment, but we might be able to add a notification 
that exposes it.  What I don't know whether that's a viable option in 
your case; it's possible that you need 'createBox' to happen before 
that point.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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'm kind of missing what's better about this compared to the other 
suggestion of hasInstance() (thanks to Botond for catching my English 
mistake!)  I'm worried a bit because of the string compare that this 
involves.


I think for things like this, as micro-optimization-land as this may 
sound, we should keep performance in mind, and before making a call we 
should try to see which variant would be faster.  Where we're 
bikeshedding over the cosmetics of the API, we should consider letting 
the faster variant win.  It's easy to write this off as non-important 
right now but generic facilities like this are bound to be used some 
day in a hot loop somewhere and then fixing things may be too costly 
due to having to change all of the existing code.


Well, the main thing is that it already exists (well, the 
string-returning version), so it seemed worth mentioning. 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.


In those cases, we tend to need something like `elem instanceof 
getGlobalForObject(elem).Element`, which is probably at least two orders 
of magnitude more expensive than the equivalent `hasClassName` call 
would be.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 
suggestion of hasInstance() (thanks to Botond for catching my English 
mistake!)  I'm worried a bit because of the string compare that this 
involves.


I think for things like this, as micro-optimization-land as this may 
sound, we should keep performance in mind, and before making a call we 
should try to see which variant would be faster.  Where we're 
bikeshedding over the cosmetics of the API, we should consider letting 
the faster variant win.  It's easy to write this off as non-important 
right now but generic facilities like this are bound to be used some day 
in a hot loop somewhere and then fixing things may be too costly due to 
having to change all of the existing code.


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2017-09-01 Thread Emilio Cobos Álvarez

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:

 * The devtools ones should be exposed only to UA sheets.
 * :-moz-empty-except-children-with-localname is only used for ,
is a super-slow selector, and we don't handle well dynamic changes to it
properly (nor is worth to try to do it, IMO).

I don't think I need to do a huge investigation to consider safe
unshipping these from content pages, but let me know if you think otherwise.

Feel free to reply here or in
, which I just
filed to this effect, if there are any concerns.

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2017-09-01 Thread Emilio Cobos Álvarez

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-mozilla-related in Github code search). Furthermore they expose
system information, which can be a fingerprinting vector, and pretty
random stuff like "is a color picker available?".

According to Boris it predates Gecko's capacity to not expose stuff.

I think it should be pretty safe to unship, but let me know if you don't
think that way, or have data that indicates the opposite.

The intention is to do that in Firefox 58, given we don't want to add
extra risk to Stylo.

Thanks!

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 "mozilla/ResultExtensions.h"

   Result
   OpenFile(const nsACtring& aPath)
   {
 nsCOMPtr file;
 MOZ_TRY(NS_NewLocalFile(aPath, false, getter_AddRefs(file)));
 return Move(file);
   }

   nsresult
   Thing::DoStuff()
   {
 nsCOMPtr file;
 MOZ_TRY_VAR(file, OpenFile(mPath));

 MOZ_TRY(file->GetNSPRFileDescriptor(...));
 ...

 return NS_OK;
   }

This works thanks to a mozilla::ToResult() helper, which MOZ_TRY calls 
to convert arbitrary types to Result (which incidentally also 
supports PRStatus by default), and GenericErrorResult type 
that auto-converts to nsresult.



As a side note, there's a particular optimization for the type 
Result so that it occupies the same amount of space as a 
bare nsresult, and code like this:


   Result MaybeThing();

   Result
   Thing()
   {
 MOZ_TRY(MaybeThing());
 return Ok();
   }

compiles to essentially the same machine code as:

   nsresult MaybeThing();

   nsresult
   Thing()
   {
 nsresult rv = MaybeThing();
 if (rv != NS_OK) {
 return rv;
 }
 return NS_OK;
   }

With the difference that the only success value MaybeThing() is allowed 
to return is NS_OK.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 remove the need to 
convert to UTF-16, since we could just use EqualsASCII.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 classname as 
HTMLEmbedElement instances. :(


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.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Eiminating nsIDOM* interfaces and brand checks

2017-09-01 Thread Bobby Holley

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', 'obj' is an instance of HTMLEmbedElement :)
>

hasInstance?


> Cheers,
> Botond
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 trying to bisect on the extensions to figure this out...


Or alternatively, install the Gecko Profiler from 
https://perf-html.io/, capture a few profiles and file bugs with them.  
Performance problems caused by add-ons are often easily visible in 
profiles.


But, alas, not always easy to trace to a particular extension as 
things stand now.


If you're looking at a local profile, though, you can at least 
figure out which extension a moz-extension: URL belongs to by 
opening about:debugging and looking at the internal UUIDs of 
installed add-ons.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 
what sort of object we have, like so:


 if (obj instanceof Ci.nsIDOMWhatever)

and we'd need to find ways to make that work.  In some cases various 
hacky workarounds are possible in terms of property names the object 
has and maybe their values, but they can end up pretty non-intuitive 
and fragile.  For example, this:


 element instanceof Components.interfaces.nsIDOMHTMLEmbedElement

becomes:

 element.localName === "embed" &&
 element.namespaceURI === "http://www.w3.org/1999/xhtml;


One possibility that should work, but is slightly ugly:

 if (ChromeUtils.getClassName(element) == "HTMLEmbedElement")

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.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Eiminating nsIDOM* interfaces and brand checks

2017-09-01 Thread Botond Ballo

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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Eiminating nsIDOM* interfaces and brand checks

2017-09-01 Thread Michael Layzell

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 good idea.
>
> I'd probably not use the name `is` though, I'd be into ehsan's suggestion
> of `isInstanceOf` (or some variant on that) much more. If we make it wordy
> enough (e.g. isInstanceOf rather than is) then it'll be easier to change in
> the future if the web platform ever implements a good solution to the
> branding problem.
>
> On Fri, Sep 1, 2017 at 11:01 AM, 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 what
>> sort of object we have, like so:
>>
>>   if (obj instanceof Ci.nsIDOMWhatever)
>>
>> and we'd need to find ways to make that work.  In some cases various
>> hacky workarounds are possible in terms of property names the object has
>> and maybe their values, but they can end up pretty non-intuitive and
>> fragile.  For example, this:
>>
>>   element instanceof Components.interfaces.nsIDOMHTMLEmbedElement
>>
>> becomes:
>>
>>   element.localName === "embed" &&
>>   element.namespaceURI === "http://www.w3.org/1999/xhtml;
>>
>> and even that is only OK at the callsite in question because we know it
>> came from http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2f
>> e7d7b6e75ad6b6b5da223/dom/interfaces/xul/nsIDOMXULCommandDis
>> patcher.idl#17 and hence we know it really is an Element...
>>
>> 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 on all DOM constructors.  So
>> "HTMLEmbedElement.is(obj)".  Possibly with some nicer but uniform name.
>>
>> 3)  Introduce chromeonly "isWhatever" methods (akin to Array.isArray) on
>> DOM constructors.  So "HTMLEmbedElement.isHTMLEmbedElement(obj)".  Kinda
>> wordy and repetitive...
>>
>> 4)  Something else?
>>
>> Thoughts?  It really would be nice to get rid of some of this stuff going
>> forward.  And since the web platform seems to be punting on branding,
>> there's no existing solution we can use.
>>
>> -Boris
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 Ghostery does a .clientHeight get with this stack:

0 setBoxHeights() 
["moz-extension://8ecb1f2d-060f-ce44-96ed-44895f11ca4b/dist/purplebox.js":128]
1 handleMessages(request = [object Object], sender = [object Object]) 
["moz-extension://8ecb1f2d-060f-ce44-96ed-44895f11ca4b/dist/purplebox.js":448]


(the rest is less important).

I reported this issue to them (copy/paste of my report below) through 
the form at https://ghostery.zendesk.com/hc/en-us/requests/new but if 
someone has better contact info that might be nice.


-Boris

Report I sent:

STEPS TO REPRODUCE:

1)  Install Ghostery in Firefox.
2)  Load https://github.com/servo/servo/
3)  Force-reload a few times.

ACTUAL RESULTS: Eventually you get a flash of unstyled content: content 
being rendered before the stylesheets are loaded.


EXPECTED RESULTS: No flashes of unstyled content.

DETAILS: The flash of unstyled content is due to Ghostery forcing a 
layout before the stylesheets are loaded.  This happens when the 
setBoxHeights() function, in purplebox.js is called from 
handleMessages(), which is handling the 'createBox' message.


setBoxHeights does this:

windowHeight = doc.documentElement.clientHeight * 0.85 - 35;

which forces layout of "doc" which in this case is the webpage being 
loaded.  If all you want is the height of the window that document is 
in, possibly with some adjustments, you could use 
`doc.defaultView.innerHeight`, or `win.innerHeight` if "win" is the 
window for "doc".  The innerHeight getter doesn't need to perform layout 
within the window itself, and won't cause this problem.


It might also be possible to not do 'createBox' until layout has started 
on the page.  I'm not sure that point in time is exposed to extensions 
at the moment, but we might be able to add a notification that exposes 
it.  What I don't know whether that's a viable option in your case; it's 
possible that you need 'createBox' to happen before that point.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 on all DOM constructors.  So 
"HTMLEmbedElement.is(obj)".  Possibly with some nicer but uniform name.


How about this slight variation:

HTMLEmbedElement.isInstanceOf(obj)

instead of "is"?

Also, is this something that we can codegen in WebIDL based on the 
presence of [HTMLConstructor] or something like that?


3) Introduce chromeonly "isWhatever" methods (akin to Array.isArray) 
on DOM constructors.  So "HTMLEmbedElement.isHTMLEmbedElement(obj)".  
Kinda wordy and repetitive...


4)  Something else?

Thoughts?  It really would be nice to get rid of some of this stuff 
going forward.  And since the web platform seems to be punting on 
branding, there's no existing solution we can use.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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.nsIDOMWhatever)

and we'd need to find ways to make that work. In some cases various
hacky workarounds are possible in terms of property names the object has
and maybe their values, but they can end up pretty non-intuitive and
fragile. For example, this:

element instanceof Components.interfaces.nsIDOMHTMLEmbedElement

becomes:

element.localName === "embed" &&
element.namespaceURI === "http://www.w3.org/1999/xhtml;

and even that is only OK at the callsite in question because we know it
came from
http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/dom/interfaces/xul/nsIDOMXULCommandDispatcher.idl#17
and hence we know it really is an Element...

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 on all DOM constructors. So
"HTMLEmbedElement.is(obj)". Possibly with some nicer but uniform name.

3) Introduce chromeonly "isWhatever" methods (akin to Array.isArray) on
DOM constructors. So "HTMLEmbedElement.isHTMLEmbedElement(obj)". Kinda
wordy and repetitive...

4) Something else?

Thoughts? It really would be nice to get rid of some of this stuff
going forward. And since the web platform seems to be punting on
branding, there's no existing solution we can use.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 alternatively, install the Gecko Profiler from https://perf-html.io/, 
capture a few profiles and file bugs with them.  Performance problems 
caused by add-ons are often easily visible in profiles.



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylesheet wait timeout?

2017-09-01 Thread Dustin Mitchell

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 issue!)
>
>
> Worth trying to bisect on the extensions to figure this out...
>
>> but I can't reproduce the FOUC in a few minutes of trying. :-|
>
>
> Again, worth trying to bisect on the extensions.  The
> not-reliably-reproducible aspect makes this a bit annoying.  :(
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #22

2017-09-01 Thread Ben Kelly

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 should
>>improve tab switching perceived performance.
>>
>
> I just want to highlight that telemetry shows that the mean tab switch
> time dropped from ~30ms to ~3ms:
>
> https://mzl.la/2grbPB2
>

Sorry, this is median. I incorrectly said mean.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #22

2017-09-01 Thread Ben Kelly

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 just want to highlight that telemetry shows that the mean tab switch time
dropped from ~30ms to ~3ms:

https://mzl.la/2grbPB2

An order of magnitude improvement! \o/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 trying. :-|


Again, worth trying to bisect on the extensions.  The 
not-reliably-reproducible aspect makes this a bit annoying.  :(


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New minimum Rust version policy for Firefox

2017-09-01 Thread Kartikaya Gupta

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 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,
> but back then Firefox required 1.15 and a webrender change broke that.
> To avoid the problem again, I added 1.15.1 to .travis.yml, but there
> were concerns about the number of travis jobs that incurred, so I
> removed stable at the same time
> (https://github.com/servo/webrender/pull/1334). Later that minimum
> version was bumped to 1.17 when Firefox bumped its requirement, but
> hasn't been bumped since.
>
> Now that Firefox nightly kinda sorta follows stable, I guess using
> stable instead of a hardcoded version again makes sense.
>
> Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Testing & "Intent to Ship"

2017-09-01 Thread James Graham

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 like to encourage everyone to be more diligent about following the 
Intent to Ship template, and recording whether the feature they want to 
enable has adequate test coverage to demonstrate compatibility with 
other browsers' existing and future implementations.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: symbol server now available via https

2017-09-01 Thread Ted Mielczarek

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'd like to add end-to-end encryption
to your symbol server requests.

Thanks to peterbe and miles and the other folks for their hard work in
updating this useful piece of infrastructure!

-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1389205
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylesheet wait timeout?

2017-09-01 Thread Gervase Markham

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 simple to debug when (A) happens:
> set a breakpoint on when we start layout and see what the JS stack is.
> The hard part is catching it happening.

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!) but
I can't reproduce the FOUC in a few minutes of trying. :-|

I will try and gather more data.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylesheet wait timeout?

2017-09-01 Thread Gervase Markham

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

I do not have Ghostery, although I do have quite a few other addons.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylesheet wait timeout?

2017-09-01 Thread Gervase Markham

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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

2017-09-01 Thread Andrew Sutherland

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 DEFAULT_REMOTE_TYPE="web".  It's not a sure thing, but I 
figure if I make it sound likely to happen and you have an opinion on 
this, you're more likely to speak up. Please chime in on the bug.  Thanks!


Andrew

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Quantum Flow Engineering Newsletter #22