Open
Bug 387669
Opened 17 years ago
Updated 2 years ago
Flash of unstyled content on this page
Categories
(Core :: General, defect)
Tracking
()
NEW
People
(Reporter: stevee, Unassigned)
References
()
Details
(Keywords: helpwanted, regression)
Attachments
(1 file)
(deleted),
patch
|
bzbarsky
:
review-
bzbarsky
:
superreview-
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/2007071104 Minefield/3.0a7pre ID:2007071104
(After the landing of bug 380028).
1. New profile, start firefox
2. Go to http://tmp.garyr.net/forum/viewforum.php?f=3
I see a flash of unstyled content as the page first loads. Ctrl-f5 will show the problem again.
No flash of unstyled content with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/2007042004 Minefield/3.0a4pre
Flash of unstyled content with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/2007042104 Minefield/3.0a4pre
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-04-20+03&maxdate=2007-04-21+05&cvsroot=%2Fcvsroot
So caused by bug 84582 i think. Taking liberty of CC'ng bz.
Comment 1•17 years ago
|
||
Mmmm. The problem here is that the markup basically looks like this (irrelevant stuff elided):
<html>
<head>
</head>
<body>
<link rel="stylesheet">
Content
</body>
</html>
So we StartLayout() when the <body> opens, then start loading the sheet, but we've already started layout, so we lay things out as we go even though there's a stylesheet pending.
I guess we can try calling StartLayout off an event on tag opens (including <body> in HTML), as discussed in bug 380028. Alternately we can introduce an API on presshell to cancel and repost reflow events and use it when stylesheet loads start/stop. The latter solution would mean we still have to reconstruct frames on this page when the sheet loads, but at least we wouldn't flash.
Maybe we want to do both: the reflow prevention so that we never see flashes, then worry about frame reconstruction issues. Of course once we don't see flashes we'll never notice the frame issues... ;)
Flags: blocking1.9?
Comment 2•17 years ago
|
||
Come to think of it, I don't think preventing reflow is a good idea. What we _really_ want to prevent are parser notifications... but the parser has to notify when an element gets closed if it's partway through that element's kids... and then the ensuing reflow event will probably catch it partway though some other element's kids, etc....
Frankly, I'm tempted to let this case go, if this is the only site with this problem that we run into. Leaving the blocking nomination, though, in case people disagree.
Comment 3•17 years ago
|
||
Steve, can you possibly test it? I've only managed to reproduce this particular FOUC once in several hundred attempts now...
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #275117 -
Flags: superreview?(jonas)
Attachment #275117 -
Flags: review?(jonas)
Comment 4•17 years ago
|
||
That is, _without_ the patch I can't really reproduce this. Which means that I can't test the patch.
And of course if there were a <script> before the <link> in the body this patch would not help... so maybe it's really not worth it.
Summary: Flash of unstyled content on this page → [FIX]Flash of unstyled content on this page
Reporter | ||
Comment 5•17 years ago
|
||
Boris, RyanVM knocked me out a build with this patch included, and it certainly seems to do the job for me; pressing ctrl-f5 on http://tmp.garyr.net/forum/ now no longer shows a flash of unstyled content. I tried this multiple times and didn't once manage to see anything unstyled.
Comment 6•17 years ago
|
||
Awesome. Thanks for testing!
Comment 7•17 years ago
|
||
Comment on attachment 275117 [details] [diff] [review]
This might help...
Sicking suggested that we add a reflow blocker on the presshell instead. That does seem to be a little more robust; I'll do that.
Attachment #275117 -
Flags: superreview?(jonas)
Attachment #275117 -
Flags: superreview-
Attachment #275117 -
Flags: review?(jonas)
Attachment #275117 -
Flags: review-
Comment 8•17 years ago
|
||
So blocking reflow on the presshell long-term while still showing stuff the the user is bad. In particular, it'll mean that attempts to interact with the page don't evidence a response (because we're not reflowing). So for example, clicking a button that changes some style will seem to have no effect...
I suppose we could have the block expire after 200ms or so. Jonas, what do you think?
Yeah, it's not really ideal, but I can't really think of anything better...
Comment 10•17 years ago
|
||
Given Comment #2 paragraph 2, not blocking on this at this point in the game. Please re-nom if you disagree.
Flags: blocking1.9? → blocking1.9-
Comment 11•17 years ago
|
||
For what it's worth, I'm going to try fixing this anyway.... it's come up on other sites too. :(
Updated•17 years ago
|
Summary: [FIX]Flash of unstyled content on this page → Flash of unstyled content on this page
Comment 12•16 years ago
|
||
For what it's worth, I'm seeing a FOUC with the style link in the header, not the body. I can duplicate it on about 1/3 of refreshes, using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008060204 Minefield/3.0pre.
The test site (which is in flux, so let me know if the failcase disappears and you need it back) is: http://www.distantmusic.com
Updated•14 years ago
|
Assignee: bzbarsky → nobody
Keywords: helpwanted
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•