1411596 - Page renders without CSS with inspector open

Status: NEW

(DevTools :: Inspector, defect, P2)

Description

[Jake Archibald [:jakea]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

https://slow-css-test.glitch.me/ - this page contains CSS that takes 10 seconds to load.

Load the page with developer tools open.


Actual results:

Page renders before CSS loads, then updates when CSS loads.


Expected results:

Rendering is blocked while CSS loads. This is what happens when devtools are closed (and what happens in all other modern browsers).

Comment 1

[Brian Grinstead [:bgrins]]

Huh, thanks for filing. I can confirm the bug when the Inspector panel has been opened. If I just open just the console panel it acts normally.

Comment 2

[Patrick Brosset <:pbro>]

Confirmed (Firefox 58, Windows 10).

The <link> node in the page points to a stylesheet that takes 10 seconds to load, so the document rendering is blocked for 10 seconds.
However, if the inspector panel is opened before loading starts, then the page renders normally, and then the stylesheet loads (and applies to the page correctly).

So there's something in the inspector that breaks the blocked rendering rule.

So far, I've tracked it down to somewhere in the construction of the markup-view. After this view has been built, it wants to mark a node as selected, and therefore gets all of the nodes from the root to it in order to show them. Doing this is what causes the early render of the page. If you just early return before that, then it works as intended (of course the markup-view is broken then).

Comment 3

[Patrick Brosset <:pbro>]

I tracked this down further, to our DocumentWalker in devtools/server/actors/inspector.js.
Just walking the DOM seems to be triggering this issue.

Here's another STR that also causes the issue:
- open the console (make sure the inspector has not been opened first),
- load the page
- quickly (within the 10 seconds), execute the following code: document.body.firstElementChild.firstElementChild
- still within those 10 seconds, expand the output node in the console to show its properties
==> Same thing happens, the unstyled content is rendered.

Brad, I could use your help here. Could you look into how <link>'d stylesheets normally block rendering of pages, and why walking the DOM while waiting would force the rendering of the page.

Comment 4

[Brad Werth [:bradwerth]]

If found another action that triggers this, that's unrelated to Developer Tools. If you start loading the page, then manually drag the bookmark icon to the bookmark toolbar, the page appears unstyled. Something all these Steps to Reproduce have in common...

Comment 5

[Brad Werth [:bradwerth]]

For the Developer Tools case, what is happening is this: As the Inspector loads, it requests the resource://devtools/server/actors/highlighters.css stylesheet. I can't yet see the JS stack that leads to this. But this loading goes through nsDOMWindowUtils::LoadSheetUsingURIString. That method forces a synchronous load of the requested sheet. The synchronous load gets handled by the same StreamLoader that is handling the delayed CSS from the page. When this load completes, the StreamLoader treats the end of the second load in the same way as it treats the end of the first load -- by triggering styling of the page.

Okay, so potential fixes will be in one of these forms:
1) If StreamLoader is never supposed to be tracking more than one load at a time (its design implies that this is the case) then what we need to do is create another StreamLoader to handle the request coming from Dev Tools.
2) If StreamLoader is supposed to handle more than one load at a time, then it's behaving poorly and needs to be fixed.
3) Dev Tools could be changed to request the stylesheet asynchronously. Other sources of this problem like the Bookmark Toolbar would need to be changed also (from comment 4).

I'll attempt to find a solution that doesn't require a change in calling patterns from all callers (option 1 or 2).

Comment 6

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #5)
> The synchronous load gets handled by the same StreamLoader that is
> handling the delayed CSS from the page.

I made a mistake; the StreamLoaders are independent. Instead, there is something downstream from Loader::SheetComplete that is triggering restyle and it is triggering when each page is marked complete -- not when ALL sheets are complete. That explains the observed behavior.

Unfortunately, in some ways this is the right thing to do. Reflowing as soon as we have new styles is what allows the Dev Tools to progressively load. It gives us perceived speed in the loading process. 

So, new possible solutions:

1) Create a barrier between chrome and content stylesheet loading notification, so new available styles in one domain won't trigger reflow of the other domain (which may not have new styles to show). This is probably the best user experience.
2) Delay restyle and reflow until ALL styles are loaded or abandoned. This is the opposite of progressive loading and would likely create a perception of slowness that would work against the real speed gains we've made in the UI.
3) Draw unstyled content as soon as we have it -- thus no problem progressively updating with each new sheet loaded. Browsers haven't done this for a long time and going back would look bad and feel bad.

So there's only one solution that wouldn't be a UI disaster. I'll create a dependent bug and see what I can do.

Comment 7

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #4)
> If found another action that triggers this, that's unrelated to Developer
> Tools. If you start loading the page, then manually drag the bookmark icon
> to the bookmark toolbar, the page appears unstyled. Something all these
> Steps to Reproduce have in common...

This Steps To Reproduce is only possible if e10s is disabled.

Comment 8

[Brad Werth [:bradwerth]]

(In reply to Brad Werth [:bradwerth] from comment #6)

> 1) Create a barrier between chrome and content stylesheet loading
> notification, so new available styles in one domain won't trigger reflow of
> the other domain (which may not have new styles to show). This is probably
> the best user experience.

This is problematic also. The devtools are not chrome content -- they are added to an anonymous content container on the canvas. It's also possible that the trigger for restyle is not the loading of the devtools stylesheet -- it could be the addition of the anonymous content container.

Comment 9

[Brad Werth [:bradwerth]]

I haven't been investigating this for awhile, and I can't prioritize it now. I'm taking myself off. The bug still occurs.

Comment 10

[Nicolas Chevobbe [:nchevobbe]]

Demo page isn't working anymore, so I created a new one: https://ffx-devtools-slow-css.glitch.me/
I can still reproduce the issue