Re: Stylesheet wait timeout?
On 9/3/17 1:04 PM, Kris Maglione wrote: The first layout flush here is happening when we focus an autofocus form field. That's longstanding https://bugzilla.mozilla.org/show_bug.cgi?id=1155812 and https://bugzilla.mozilla.org/show_bug.cgi?id=712130 -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet wait timeout?
On Sun, Sep 03, 2017 at 12:40:04PM -0400, Dustin Mitchell wrote: I just reproduced it with a random page from my history: https://github.com/taskcluster/taskcluster-cli/issues/49. Any github page will do, and it seems to have to do with caching. if I delete today's history, I can reproduce. And with a repro recipe, I can capture a profile -- https://perfht.ml/2wxZIpP Interesting. The first layout flush here is happening when we focus an autofocus form field. I'd be surprised if anything about that changed recently, but it does seem like something that should wait until after the first layout flush. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet wait timeout?
Oops, the profile is from a *different* random github page from my history, sorry for any confusion. 2017-09-03 12:40 GMT-04:00 Dustin Mitchell : > I just reproduced it with a random page from my history: > https://github.com/taskcluster/taskcluster-cli/issues/49. Any github > page will do, and it seems to have to do with caching. if I delete > today's history, I can reproduce. And with a repro recipe, I can > capture a profile -- https://perfht.ml/2wxZIpP > > Dustin > > 2017-09-02 16:58 GMT-04:00 Panos Astithas : >> On Fri, Sep 1, 2017 at 7:37 PM, Boris Zbarsky wrote: >> >>> 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. >>> >> >> I have forwarded your message to my contacts at Cliqz (new owners of >> Ghostery) and pointed them to this thread as well. >> >> Panos >> ___ >> 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?
I just reproduced it with a random page from my history: https://github.com/taskcluster/taskcluster-cli/issues/49. Any github page will do, and it seems to have to do with caching. if I delete today's history, I can reproduce. And with a repro recipe, I can capture a profile -- https://perfht.ml/2wxZIpP Dustin 2017-09-02 16:58 GMT-04:00 Panos Astithas : > On Fri, Sep 1, 2017 at 7:37 PM, Boris Zbarsky wrote: > >> 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. >> > > I have forwarded your message to my contacts at Cliqz (new owners of > Ghostery) and pointed them to this thread as well. > > Panos > ___ > 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 1, 2017 at 7:37 PM, Boris Zbarsky wrote: > 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. > I have forwarded your message to my contacts at Cliqz (new owners of Ghostery) and pointed them to this thread as well. Panos ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet wait timeout?
On 9/2/17 8:43 AM, Dustin Mitchell wrote: The flashes (just saw another a moment ago) are on github.com. On which exact page(s), if I might ask? For reproducing this sort of thing details matter, so if you know what exact URL you saw it on that would be very helpful. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stylesheet wait timeout?
I haven't distinguished between those two options -- I was making the point that Ghostery isn't (exclusively) to blame. Yes, it's that test pilot. The flashes (just saw another a moment ago) are on github.com. Dustin 2017-09-01 17:01 GMT-04:00 Boris Zbarsky : > 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 ___ 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 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's possible, to some extent (extensions could get around it by just executing code in the page context rather than their sandbox), but not exactly trivial. It would also probably break too many extensions to be feasible. Another alternative, can we prevent extensions from injecting content in webpages before layout has started? No. A lot of extensions depend on being able to run code before any page scripts have executed (and we hear from them when that doesn't work the way they expect). We could do this for content scripts that ask to run with idle dispatch, but that wouldn't help with (for example) Ghostery. On 1 Sep 2017, at 22:57, Ehsan Akhgari wrote: 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation It is the mark of an educated mind to be able to entertain a thought without accepting it. --Aristotle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 in webpages before layout has started? > On 1 Sep 2017, at 22:57, Ehsan Akhgari wrote: > > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 content on? -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: 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: 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: 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?
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: 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: 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 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?
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?
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
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 you're getting FOUC then either someone put s outside or there's script querying layout. And to the extent that said script is an add-on or our UI, that needs to be fixed. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 1283302, it was after a lengthy user study that indicated a higher perceived performance score when we paint sooner. We knew that FOUC (flash of unstyled content) could happen more often, but perhaps it's happening more often now that we paint faster. --Jet [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1283302 On Thu, Aug 31, 2017 at 10:24 AM, Gervase Markham wrote: > 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 later with style. It happens for me quite a bit on xkcd.com, > but there are other pages too. > > I think we may have set the timeout a bit low, because the result is ugly. > > I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS. > > Gerv > ___ > 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 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 to happen for me. YMMV. From a quick look at Ghostery, it apparently injects UI elements into content pages to notify you of things it's blocked, and to do that, it queries the page layout state (several times). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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. > 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. > > -Michael. > > ___ > 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 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 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. 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. -Michael. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 top priority loads, none of the bugs we have landed for CDP has changed this. -hb- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 lately on Nigthly. I’ve reproduced it both with and without Stylo. -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 information or B) We have seen and all stylesheets whose loads started due to the parser inserting elements are done loading. (Note that this means we always wait for the elements in , and may wait for the ones in , depending on whether we manage to start their loads before the ones from finish loading.) 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. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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 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 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 later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.
I think we may have set the timeout a bit low, because the result is ugly.
I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.
Gerv
___
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?
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 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 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 later with style. It happens for me quite a bit on xkcd.com,
>> but there are other pages too.
>>
>> I think we may have set the timeout a bit low, because the result is ugly.
>>
>> I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.
>>
>> Gerv
>>
>
> ___
> 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?
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 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 later with style. It happens for me quite a bit on xkcd.com, but there are other pages too. I think we may have set the timeout a bit low, because the result is ugly. I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 later with style. It happens for me quite a bit on xkcd.com, but there are other pages too. I think we may have set the timeout a bit low, because the result is ugly. I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
