Issue metadata
Sign in to add a comment
|
Unexplained DOM properties while loading HTML imports |
||||||||||||||||||||||||
Issue descriptionVersion: At least 52-54 OS: At least Linux I was having an issue similar to issue 516550 , but narrowed it down to an example with no stylesheets or custom elements. Also sounds related to issue 481122 and issue 521692, but again, no CSS at all. 1. Have an element in the <body> 2. Have a script (inline or external or import) that schedules a rAF + setTimeout to query the element's offsetHeight 3. Have a <link rel="import"> after 1 and 2 Expected: In the rAF + setTimeout callback, the element's offsetParent is <body> and it has a normal offsetHeight. Actual: Sometimes, the element's offsetParent is null, and offsetHeight is 0. Some notes: * Happens whether the script is inline, external, or in an HTML import. * Happens only if the script is followed by another <link rel="import">. * Does not reproduce 100%. Here's a minimal example: <!doctype html> <body> <div>Hello, world</div> <!-- This can also be an external script or HTML import. --> <script> var div = document.body.querySelector('div'); requestAnimationFrame(function() { setTimeout(function() { console.log('rAF + setTimeout: document.readyState', document.readyState); console.log('rAF + setTimeout: div.offsetParent', div.offsetParent); console.log('rAF + setTimeout: div.offsetHeight', div.offsetHeight); }, 0); }); </script> <!-- wait on an import, which can be blank or even 404 --> <link rel="import" href="foo.html"> </body> The output usually shows that the <div> is in an unusable state in the callback: > rAF + setTimeout: document.readyState interactive > rAF + setTimeout: div.offsetParent null > rAF + setTimeout: div.offsetHeight 0 Although this creates no stylesheets, it seems issue 521692 may be relevant. The practical relevance here is the inability to know when the DOM can be queried in a complex page (e.g. MD Settings), as rAF + setTimeout is the guidance for guaranteeing a render. Also related to this Polymer bug: https://github.com/Polymer/polymer/issues/3629
,
Aug 17 2016
Adding loader for document.readyState
,
Aug 18 2016
This is just more of the same problem that is issue 521692. The import in the body is racing the raf, depending on when the frame pumps and when the import is processed you can get different behavior. We need to switch all sheets and imports in the body to not be render blocking. pmeenan@ What's the status here? We either need to block the parser or make the stuff async. Progress here would be great. :)
,
Aug 19 2016
,
Aug 25 2016
In-body sheets are async behind a flag but it doesn't change the behavior of imports. I'm back to looking at the parser blocking right now but the main issue is that it is technically against the HTML5 parsing spec to block parse for sheets. The only thing that is allowed to set the "parser pause flag" to true currently is a script: http://w3c.github.io/html/syntax.html#parsing-html-documents Hopefully it won't take more than a couple of days to get the actual parsing change made (behind a flag) but I'm not sure how likely we are to get the spec updated. Last time I tried it was actually suggested that we file a bug against Edge who implement the parser-blocking instead.
,
Aug 31 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787 commit d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787 Author: pmeenan <pmeenan@chromium.org> Date: Wed Aug 31 23:03:35 2016 Added a use counter for in-body external stylesheets This will give us an idea for how common it is to have in-body external stylesheets and gauge the impact of making them not block paint or determine if we need stronger protection like blocking the HTML parser. BUG= 481122 , 638074 Review-Url: https://codereview.chromium.org/2286793002 Cr-Commit-Position: refs/heads/master@{#415792} [modify] https://crrev.com/d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787/third_party/WebKit/Source/core/core.gypi [add] https://crrev.com/d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787/third_party/WebKit/Source/core/dom/StyleEngineContext.cpp [modify] https://crrev.com/d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787/third_party/WebKit/Source/core/dom/StyleEngineContext.h [modify] https://crrev.com/d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787/third_party/WebKit/Source/core/frame/UseCounter.h [modify] https://crrev.com/d9d7833ff2b2d90cb54bd5cd184c00c58e2ac787/tools/metrics/histograms/histograms.xml
,
Aug 31 2016
I think we can deal with the spec change later. Strictly speaking the parser can pause for any number of reasons, for example we slow it way down it in background tabs, or pause it when you touch the screen to handle input. Blocking it on a stylesheet wouldn't be observable beyond the user touching the screen and scrolling up and down and us prioritizing input over parsing. If this change sticks we can then consider getting the HTML spec changed.
,
Mar 7 2017
,
Mar 23 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by schenney@chromium.org
, Aug 16 2016