Summary: | Allow the page to render before <link> stylesheet tags in body | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Jake Archibald <jaffathecake> | ||||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | commit-queue, dino, eoconnor, koivisto, ryanhaddad, sam, simon.fraser, webkit-bug-importer | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | WebKit Nightly Build | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Bug Depends on: | 169079, 169277, 169465, 170040 | ||||||||||
Bug Blocks: | |||||||||||
Attachments: |
|
Description
Jake Archibald
2015-09-15 03:49:01 PDT
I realise the videos in the previous comment don't show the effect in Safari specifically, unfortunately WPT doesn't support it, but testing with the Network Link Conditioner shows it to have the same issue as Chrome. Chrome is planning to ship this: https://jakearchibald.com/2016/link-in-body/ > In Chrome/Safari, the preparser discovers the CSS and blocks further
> rendering, including content before the <link>.
This is not true in WebKit. Stylesheet loads triggered by preload scanner don't block rendering. Rendering is only blocked when the real parser reaches a loading <link> element (or <style> with @import).
Created attachment 303826 [details]
patch
*** Bug 169345 has been marked as a duplicate of this bug. *** Comment on attachment 303826 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=303826&action=review > Source/WebCore/rendering/RenderBlock.cpp:1575 > + // Style is non-final if the element has a pending stylesheet before it. We end up with renderers with such styles if a script > + // forces renderer construction by querying something layout dependent. Is this comment accurate with <link rel="stylesheet"> in the body? Won't we force renderer construction anyway? > Source/WebCore/style/StyleTreeResolver.cpp:171 > + m_document.setHasNodesWithNonFinalStyle(); Wehre is this cleared? I see no calls to m_document.setHasNodesWithNonFinalStyle(false) > Source/WebCore/style/StyleTreeResolver.cpp:184 > + m_document.setHasNodesWithNonFinalStyle(); Ditto. > Is this comment accurate with <link rel="stylesheet"> in the body? Won't we > force renderer construction anyway? In normal case we only compute style (and so construct renderers) up to the loading in-body stylesheet. Call to updateLayoutIgnorePendingStylesheet() forces renderer construction for all elements. In that case we generate renderers with non-final style. > Wehre is this cleared? I see no calls to > m_document.setHasNodesWithNonFinalStyle(false) Document::resolveStyle() has m_hasNodesWithNonFinalStyle = false; > Document::resolveStyle() has
>
> m_hasNodesWithNonFinalStyle = false;
...when we do full style rebuild.
(In reply to comment #9) > > Document::resolveStyle() has > > > > m_hasNodesWithNonFinalStyle = false; > > ...when we do full style rebuild. It would make searching easier if this called the setHasNodesWithNonFinalStyle() function > It would make searching easier if this called the
> setHasNodesWithNonFinalStyle() function
I don't want to make setHasNodesWithNonFinalStyle take an argument since no one except Document itself should reset the flag.
Comment on attachment 303826 [details] patch Clearing flags on attachment: 303826 Committed r213633: <http://trac.webkit.org/changeset/213633> All reviewed patches have been landed. Closing bug. *** Bug 169345 has been marked as a duplicate of this bug. *** Reverted r213633 for reason: This change caused LayoutTest imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/sizes/parse-a-sizes-attribute.html to become a flaky failure. Committed r213701: <http://trac.webkit.org/changeset/213701> *** Bug 169452 has been marked as a duplicate of this bug. *** Fix for bug 169465 should make imported/w3c/web-platform-tests/html/semantics/embedded-content/the-img-element/sizes/parse-a-sizes-attribute.html reliable. Comment on attachment 303826 [details] patch Rejecting attachment 303826 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-02', 'validate-changelog', '--check-oops', '--non-interactive', 303826, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in LayoutTests/ChangeLog contains OOPS!. Full output: http://webkit-queues.webkit.org/results/3283697 Created attachment 304042 [details]
patch
Comment on attachment 304042 [details] patch Clearing flags on attachment: 304042 Committed r213712: <http://trac.webkit.org/changeset/213712> All reviewed patches have been landed. Closing bug. Reverted in http://trac.webkit.org/changeset/214333 due to iPad PLT regression. Created attachment 305510 [details]
patch
Comment on attachment 305510 [details] patch Clearing flags on attachment: 305510 Committed r214435: <http://trac.webkit.org/changeset/214435> All reviewed patches have been landed. Closing bug. |