Closed Bug 387669 Opened 17 years ago Closed 8 months ago

Flash of unstyled content on this page

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: stevee, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, regression)

Attachments

(1 file)

This might help...
2.60 KB, 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.
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?
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.
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)
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
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.
Awesome. Thanks for testing!
Blocks: 396099
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-
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...
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-
For what it's worth, I'm going to try fixing this anyway.... it's come up on other sites too. :(
Summary: [FIX]Flash of unstyled content on this page → Flash of unstyled content on this page
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
Blocks: 445903
Assignee: bzbarsky → nobody
Keywords: helpwanted
Is this still a bug? Seems to work for me.
Status: ASSIGNED → NEW
Severity: normal → S3

Website no longer available

Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: