FOUC caused by a hidden input in the <head> tag
Categories
(Core :: Layout, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox66 | --- | affected |
People
(Reporter: twisniewski, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
444 bytes,
text/html
|
Details |
It appears that in the attached test-case, a FOUC (flash of unstyled content) is being caused by the <input type=hidden> in the <head> of the document. The delay is more noticeable if the stylesheet takes longer to download, but doesn't seem to be tied to the specific stylesheet I've used in the test-case (I tried a stylesheet from the BBC site, among others, and they all caused a flash relative to the time it took to fetch the remote CSS file).
|
||
Comment 1•5 years ago
|
||
Well, the <input> causes the <head> to end and the <body> to begin, so the <link> after that is in the body, which doesn't block layout IIRC.
Boris, do you have any opinion on what to do about this? You were involved in the discussion in:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/QC5iefctcag/kkoBNliBAgAJ
Which seems relevant to this and looks like it'd regress this in Chromium.
|
||
Comment 2•5 years ago
|
||
Yes to all of comment 1.
Note that <input> is not allowed in <head> in valid HTML, by the way, not that anyone really cares about HTML validity...
Boris, do you have any opinion on what to do about this?
Is this being a problem on real-world sites?
|
|
||
Comment 3•5 years ago
|
||
Looks like at least on https://webcompat.com/issues/20307, yes.
|
|
||
Comment 4•5 years ago
|
||
OK, so specifically this has been seen on https://watchmyparcel.com/hm only (the other link in that issue does not have this pattern).
|
|
||
Updated•5 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Comment 5•2 years ago
|
||
Tom, you wanted to check if this has a lot of instances and maybe should be a P2 instead of a P3.
|
Reporter | |
Comment 6•2 years ago
|
||
I don't see any hard evidence that this is impacting a lot of sites in a bad way, so since there's a listed workaround on a related chromestatus page I think this can remain a P3 for now:
Firefox .. does not pause the parser so that content after the external sheet is painted using the existing styles until the external sheet loads. Parser pausing can be achieved in Firefox by placing an empty script tag after the relevant sheets.
|
||
Updated•2 years ago
|
|
||
Comment 7•9 days ago
|
||
I've rechecked https://webcompat.com/issues/20307 and the issue is no longer reproducible (they moved <input name="__RequestVerificationToken> inside the body tag). Unsetting webcompat priority for now
Description
•