Flash of unstyled content on this page

NEW
Unassigned

Status

()

Core
General
11 years ago
7 years ago

People

(Reporter: stevee, Unassigned)

Tracking

({helpwanted, regression})

Trunk
x86
Windows 2000
helpwanted, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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.
Created attachment 275117 [details] [diff] [review]
This might help...

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
(Reporter)

Comment 5

11 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.
Awesome.  Thanks for testing!
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

Comment 12

10 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

10 years ago
Blocks: 445903
Duplicate of this bug: 445903
Assignee: bzbarsky → nobody
Keywords: helpwanted

Comment 14

7 years ago
Is this still a bug? Seems to work for me.
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.