Open Bug 1404468 Opened 7 years ago Updated 1 month ago

Various websites like GitHub load with flash of unstyled content (FOUC)

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Version:
55 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 - wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- fix-optional

People

(Reporter: micah, Unassigned, NeedInfo)

References

(Depends on 3 open bugs)

Details

(Keywords: compat, regression, regressionwindow-wanted) 

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053838

Steps to reproduce:

1. Enter URL in address bar: https://adactio.com/
2. Load the website


Actual results:

When the website starts loading, the first thing to show is markup without styles. Styles then apply to markup and website looks designed.

The best way to see this in action is loading a non-cached site and with throttled bandwidth or on a slow connection. I also was able to simulate it with Responsive Design Mode's throttled speeds.


Expected results:

Website should not show markup before styles are applied.
This is similar behavior that is reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=712130

Adactio, however, does not contain the autofocus attribute on any input elements and still shows FOUC. Other websites I tested which did not have any script elements in the head element, they all suffered from FOUC.
[Tracking Requested - why for this release]: I think this is worthy of being investigated further and fixed for the next releases.
status-firefox55: --- → affected
status-firefox56: --- → affected
status-firefox57: --- → affected
status-firefox58: --- → affected
status-firefox-esr52: --- → affected
tracking-firefox58: --- → ?
I also see this on https://navyfederal.org when attempting to sign in.
Component: Untriaged → Layout
Product: Firefox → Core
I am getting a lot of annoying FOUC on most pages I visit with Firefox Quantum (macOS High Sierra, Firefox Quantum 57.0b6 (64-bit)). Would really love to see this patched because the browser is otherwise amazing!
Priority: -- → P3
For http://kanbasu.liip.ch/ at least, the FOUC is a clear regression between firefox-esr (52.5.0) and firefox (57.0).

We also see a terrible FOUC on https://styleguide.liip.ch/ and a limited one on https://www.liip.ch/
Also https://github.com/liip/kanbasu/ has a clearly worsened FOUC between the same versions. I figured GitHub would be a more interesting target.
I've seen GitHub FOUC recently; checking their source code I can confirm their CSS are all referenced in the <head> as <link>s.

It's definitely a regression given we have break away from what's described (unfortunately, unspec'd behavior) here:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ZAPP8aTnyn0/hHzIdC-GCAAJ

Astley, this is what we have talked about earlier. This is a critical behavior that websites rely on to ensure their experience; I would worry this breaks compat too. Would you be interested in figuring out what had regressed this?
Flags: needinfo?(bmo)
Keywords: compat, regression, regressionwindow-wanted
Summary: Websites load with flash of unstyled content (FOUC) → Various websites like GitHub load with flash of unstyled content (FOUC)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #8)
> Astley, this is what we have talked about earlier. This is a critical
> behavior that websites rely on to ensure their experience; I would worry
> this breaks compat too. Would you be interested in figuring out what had
> regressed this?

I can easily see the FOUC on Github page in RDM mode with throttled network speed to 2G.
Thanks for pointing it out, I'll look into it further.
It also happens for extensions that show content on new tabs. Example: https://addons.mozilla.org/en-US/firefox/addon/earth-view-from-google/
Many of the symptoms noted here are reduced by reverting the fix to bug 1283302.

I'd note that our user studies on bug 1283302 indicated an overall positive user response to painting sooner. We can revisit the decision given Firefox 57's much faster overall rendering speed, but the potential for FOUC was definitely a known factor in the change:

https://bugzilla.mozilla.org/show_bug.cgi?id=1283302#c0
Jet, is there anything sites can do to mitigate this on their end?
Flags: needinfo?(bugs)
Boris suggests adactio.com is doing some flickering on load due to not providing width/height on the images.  So we are doing layout before we know the image sizes.

Dropping my NI since I guess a lot of the issues are otherwise explainable.
Flags: needinfo?(bugs)
> is there anything sites can do to mitigate this on their end?

It really depends on the site.  Generally, I would say "Put all your styles in <head> and make sure that any script that asks for layout information comes after them".

What we should do on our end is fix the autofocus thing.  Past that, looking at the links in this bug:

https://adactio.com/ -- I can't reproduce FOUC, even when force-reloading.  It loads pretty much instantaneously, with styles, except for the images.   If I throttle to "GPRS" in responsive design mode, it's much slower, but still no FOUC: pops in with all styles applied.  If someone is seeing FOUC on this site and also compiling Firefox I'm happy to walk you through debugging it.  If someone is seeing FOUC on this site and not compiling Firefox, I'd like more information on your extensions and whatnot.

https://navyfederal.org/ -- Assuming this is talking about the failed sign-in case, i.e. at <https://my.navyfederal.org/NFOAA_Auth/login.jsp>, that page does autofocus.

http://kanbasu.liip.ch/ -- As for adactio.com: can't reproduce FOUC, even with throttling.  Need help reproducing.

https://styleguide.liip.ch/ -- Can't reproduce FOUC, need help reproducing.

https://www.liip.ch/ -- Can't reproduce FOUC, though on a force-reload I do get the text showing before the webfont finishes loading.

https://github.com/liip/kanbasu/ -- Can't reproduce either (there's no autofocus field for me on this particular github page, even when not logged in, fwiw).

https://github.com/php/php-src/blob/php-7.2.0RC6/NEWS -- likewise can't reproduce.  :(

I haven't tested the exension mentioned in comment 11.
Boris, should I create a screencast of Adactio's behavior? When I throttle go "GPRS" in RDM, it first shows the markup and then applies the style. I can reproduce this in all current versions of Firefox without any addons installed.
Another site that seems to do more FOUC in firefox vs chrome

https://codepen.io/pen/
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #16)
> http://kanbasu.liip.ch/ -- As for adactio.com: can't reproduce FOUC, even
> with throttling.  Need help reproducing.
> 
> https://styleguide.liip.ch/ -- Can't reproduce FOUC, need help reproducing.
> 
> https://www.liip.ch/ -- Can't reproduce FOUC, though on a force-reload I do
> get the text showing before the webfont finishes loading.
> 
> https://github.com/liip/kanbasu/ -- Can't reproduce either (there's no
> autofocus field for me on this particular github page, even when not logged
> in, fwiw).
> 
> https://github.com/php/php-src/blob/php-7.2.0RC6/NEWS -- likewise can't
> reproduce.  :(
> 
> I haven't tested the exension mentioned in comment 11.

I've find it easier to reproduce if I start a `mach build` in the background... :) It's kind of unrelated to the network (there is no need to use network throttling or RDM mode).

(In reply to Jet Villegas (:jet) from comment #12)
> Many of the symptoms noted here are reduced by reverting the fix to bug
> 1283302.
> 
> I'd note that our user studies on bug 1283302 indicated an overall positive
> user response to painting sooner. We can revisit the decision given Firefox
> 57's much faster overall rendering speed, but the potential for FOUC was
> definitely a known factor in the change:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1283302#c0

Thanks for the comment. I first noticed this with the EarthView from Google extension (comment 11). 

Could you help me understand what the timeout in bug 1283302 is really waiting for? My tests show that we still block rendering if we are waiting for stylesheet from the network (can be quickly tested with [1]), so I am a bit confused about what time'd out when the stylesheet came from an extension package or local cache. Do we give up CSS parsing or whatnot after 5ms now? If so that explains it...

[1] data:text/html,<html><head><link rel="stylesheet" href="http://192.168.123.123/thiswilltimeout.css"></link></head><body><h1>Youshouldnotseethissoon</h1></body></html>
(In reply to Ben Kelly [:bkelly] from comment #18)
> Another site that seems to do more FOUC in firefox vs chrome
> https://codepen.io/pen/

I've filed bug 1420362 for FOUC issue on a site with <iframe> in its body.
Flags: needinfo?(bmo)
See Also: → 1420362, 712130
Another FOUC page slightly worse in Firefox than Chrome: https://inciweb.nwcg.gov/

(I hope it's useful to post examples here as I see them)
Even the wiki of Mozilla has this problem : https://wiki.mozilla.org/Main_Page
(don't forget to clear the cache with Ctrl+F5 to see it).
I think there are enough examples now?
Hi, I can see that the bugs about FOUCs are still not fixed... It seems that they are annoying visual bugs, I wonder why anyone (from mozilla?) works on...
Is someone here can do something or that's not a priority right now?
Thanks.
Flags: needinfo?(bugs)
(In reply to Julien L. from comment #24)
> Hi, I can see that the bugs about FOUCs are still not fixed... It seems that
> they are annoying visual bugs, I wonder why anyone (from mozilla?) works
> on...
> Is someone here can do something or that's not a priority right now?
> Thanks.

Please see my earlier comment 12.
Flags: needinfo?(bugs)
I did extensive testing this evening to test the FOUC issues I originally reported in other instances of Firefox, starting with Firefox Developer Edition.

I have found one add-on in particular that causes it: https://addons.mozilla.org/en-US/firefox/addon/ebates/

I tried many various combinations of add-ons to see what happened with FOUC on the various sites mentioned here. While FOUC does still exist without the above add-on with other sites, sometimes due to autofocus or other reasons, I was able to reproduce FOUC consistently with the Ebates add-on.

This is proof that add-ons are at least a second reason why FOUC occurs in Firefox, with or without autofocus being an issue.

I would like to recommend all reporters in this thread to download Firefox Developer Edition and test their sites without add-ons.
https://www.mozilla.org/en-US/firefox/developer/

If you aren't able to see FOUC right away, start adding the add-ons your normal Firefox is using until you can reproduce FOUC that you reported.
Enabling the Ghostery Firefox addon causes https://github.com/ to have a FOUC on load.
I can confirm I see similar behavior on Firefox Dev Edition 59.0b1 on macOS with only Ghostery extension and Github.com while logged in. When visiting Github logged out, it already suffers from FOUC b/c of the autofocus bug https://bugzilla.mozilla.org/show_bug.cgi?id=712130
Just wanted to add that I see the same thing (58.0.1 64bit Windows 7 Pro).  In my case, it's partially caused by the Imagus extension on some pages/sites.

I made this thread: https://www.reddit.com/r/imagus/comments/7v52mc/firefox_58_and_odd_imagus_rendering_issue_at_a/

I can make it always happen here: https://www.mysstie.com/systeminfo.shtml if I don't disable Imagus at that domain.  What's weird, if I load a Javascript file or something at the bottom, then that unstyled flash goes away.
Too late to fix this in 58.  Would it help to break out the particular causes/STR into dependent bugs, here?
status-firefox57: fix-optional → wontfix
status-firefox58: affected → wontfix
status-firefox59: --- → fix-optional
status-firefox60: --- → affected
(In reply to MarkRH from comment #29)
> I can make it always happen here: https://www.mysstie.com/systeminfo.shtml
> if I don't disable Imagus at that domain.  What's weird, if I load a
> Javascript file or something at the bottom, then that unstyled flash goes
> away.
I can reproduce this on Nightly. I do have Imagus and Adblock Plus enabled. Boris can you take a look?
Flags: needinfo?(bzbarsky)
> Would it help to break out the particular causes/STR into dependent bugs, here?

YES!  People should definitely do that, because this sort of thing can be caused for a variety of reasons.

Looking over the last few comments:

1) There is a known issue with Ghostery.  It was reported to them; see bug 712130 comment 90.

2) I filed bug 1437644 on the Imagus issue from comment 29.
Depends on: 1437644
Flags: needinfo?(bzbarsky)
AdBlocker Ultimate definitely causes FOUC on a lot of websites!

An extreme example can be seen on this site: http://www.sitiodosnegocios.pt/
Try navigating on the site's main menu bar with AdBlocker enabled; you'll see an extreme FOUC effect.
Then disable the extension and navigate the website again: pages will seem to load instantly.

AdBlocker probably injects scripts on web pages, which could change the way Firefox renders stylesheets, as the layout and rendering algorithm is affected by the presence and location of script tags.
In regards to this ticket, Ghostery v8.0.9 fixed the FOUC issue on our end.
I can only reproduce the FOUC on https://inciweb.nwcg.gov/ (from all given links in this thread) with my machine (Ubuntu 16.04, Firefox 58)
But since they set css inside of the body like this: 
<style type="text/css">
@import url("/style/style.php");
</style>
... it is the programmers fault.

In any other cases, I think bad written plugins are the problem. I hustle with Adblocker Plus, YouTube Enhancer, Video Download Helper, HTTPS Everywhere, Violentmonkey and NoScript. Everything is fine with these plugins. No FOUC's given.

@Alex: Yes, you are obviously right, but smartasses will get a Mac to work with Windows Software for all eternity, you know...
(In reply to Tim Wahrendorff from comment #39)
>> ... it is the programmers fault.
> 
> In any other cases, I think bad written plugins are the problem. I hustle
> with Adblocker Plus, YouTube Enhancer, Video Download Helper, HTTPS
> Everywhere, Violentmonkey and NoScript. Everything is fine with these
> plugins. No FOUC's given.

I don't think it is the websites' fault. It is a bug of Firefox.
With a clean profile, I can see FOUCs on many websites with my laptop computer (intel i5-4200M, 8 GB DDR3, HDD...) in Firefox nightly 60.
With a faster machine, it is less obvious to see these FOUCs.
Julien L, can you test the various websites that give you FOUC on Firefox Developer Edition and do so without any add-ons installed?
https://www.mozilla.org/en-US/firefox/developer/

I agree that there's a bug, one of which I referenced in my first posts and has to do with autofocus, but that problem is fixed as indicated in that thread. If you could list the sites where you see FOUC, I'd like to test it on my computer on Firefox as well.

Some of the sites listed in this thread seem to have improved in the latest versions of Firefox, but one site that still consistently causes FOUC on refresh is https://codepen.io/pen/, even in Firefox Dev and Firefox 60.
I can see FOUC on these websites (that are just a selection) :
http://www.jeuxvideo.com/
https://wiki.mozilla.org/RapidRelease/Calendar
https://github.com/gorhill/uBlock/releases
https://codepen.io/pen/
https://inciweb.nwcg.gov/
https://www.mysstie.com/systeminfo.shtml

Please note that you have to erase the cache in order to see the "flashes" (Ctrl+F5).
With Firefox 60, I noticed that the rendering is a bit faster, so these FOUC happens quicker.
I can verify that three of Julien's URLs are worse than the others. Using Firefox Dev Edition 60.0b2, no add-ons:

http://www.jeuxvideo.com/ -- This is the worst of the bunch, with the most noticeable FOUC that even on a ~100Mbps connection shows almost one second of FOUC. I see almost 30 HTTP requests before the styles are applied to get past the FOUC.

https://inciweb.nwcg.gov/ -- This is almost as severe as the site above. There's a combination of @import CSS, external and internal CSS and JS that appear to be render blocking. The first external JS, https://js.arcgis.com/3.20compact/, appears to be rendering blocking by pulling in several other external scripts. During that time is when I first saw the bare markup without styling.

And Codepen is similar to the two above, less noticeable but still present. I don't see autofocus on any of them either.
> http://www.jeuxvideo.com/

This has a pretty obvious FOUC, yes.  The site is doing an offsetParent get from script that runs off a 0ms setTimeout.  This timeout is started before any of the stylesheet loads even start and is basically a timeout loop trying to detect whether an ad blocker is being used...

In any case, it's asking for layout information before the sheets have loaded, so we start layout, and then when more content comes in you get a FOUC until the sheets are done loading.  Short of doing something like Chrome and blocking the parser on stylesheets I'm not sure what we can do here.

> https://wiki.mozilla.org/RapidRelease/Calendar

I'm not sure I'm managing to reproduce this.  I do see the "webfonts are loading" flicker where the text is invisible and then appears once the fonts load, but not other changes to styling or layout...

> https://github.com/gorhill/uBlock/releases

Again, can't reproduce FOUC with today's nightly build here....

> https://codepen.io/pen/

Tracked in bug 1420362.

> https://inciweb.nwcg.gov/

Again, can't reproduce, in a clean profile.  The background images take some time to load, but that's all I see there.

> https://www.mysstie.com/systeminfo.shtml

I'm aware of a FOUC there with some addons (e.g. bug 1437644) but not in a vanilla profile...
Depends on: 1420362
This is happening for me with FF 59.0.2 (64-bit) on OSX El Capitan 10.11.6  at the following sites: 

https://github.com/
https://github.com/gorhill/uBlock/releases
https://wiki.mozilla.org/RapidRelease/Calendar
https://www.mysstie.com/systeminfo.shtml


Tried it with AdBlock disabled / enabled - same result.
> This is happening for me with FF 59.0.2

Given that bug 712130 is fixed in 60, any data from 59 or earlier is of somewhat limited utility.

> https://wiki.mozilla.org/RapidRelease/Calendar

Any add-ons involved?  There's nothing on this page that should be triggering FOUC.

> https://www.mysstie.com/systeminfo.shtml

Again, any add-ons involved?  See bug 1437644.

Adblock is _not_ the only add-on that can cause FOUC.
No other add-ons involved, vanilla install.  Can't wait for v60 to hit. Thanks!
In that case, I don't understand what you're seeing on https://wiki.mozilla.org/RapidRelease/Calendar and https://www.mysstie.com/systeminfo.shtml...

If you're able to do a video capture that shows what you see and email me a link, that would be pretty useful.  I understand if that's not an option.
Check out these screen recordings. What I'm doing is hitting Command + R:

https://www.laurencegellert.com/content/FF_FOUC.mov
https://www.laurencegellert.com/content/FF_FOUC_2.mov
OK.  That second recording definitely shows FOUC...  You're sure this is without any add-ons installed?  I've been trying to reproduce and haven't been able to so far.  :(
Good news, when I disable AdBlocker Ultimate, the problem goes away for:
https://wiki.mozilla.org/Release_Management/Calendar
https://www.mysstie.com/systeminfo.shtml
https://github.com/gorhill/uBlock/releases

But github's home page still does it.
https://github.com/

Sorry for my poor QA testing ;) So it must be the plugin AND something strange about github.com unrelated to the plugin.
> But github's home page still does it.

Yes, that's bug 712130, fixed in 60.
Hi!
I've just disabled my extension S3.Translator and then loaded the webpage https://wiki.mozilla.org/Release_Management/Calendar
and it solves the problem. There are no FOUC with this extension disabled, except on that website : https://codepen.io/pen/
But I never go on that website so it's not a problem, and I don't think it should really considered as a FOUC.
Should I contact the author of S3.Translator?
Flags: needinfo?(bzbarsky)
> https://codepen.io/pen/

Right, that's tracked by bug 1420362.

> Should I contact the author of S3.Translator?

Probably a good idea, yes.
Flags: needinfo?(bzbarsky)
I have contacted the author of S3.Translator on April 11st (2018) in the official thread ( http://forums.mozillazine.org/viewtopic.php?f=48&t=2829503&p=14799107&sid=88bb9f29e387d193bb231acba3546c42#p14799107 ) and I don't have any answer. Yet he answers to the critics on AMO.
There is still a FOUC issue with these websites and the extension S3.Translator (for instance) :
https://forums.lanik.us/viewforum.php?f=23
https://wiki.mozilla.org/Release_Management/Calendar
http://www.revivre.org/forum/index.php

I'm gonna post a critic on AMO about that...
I see it nearly every time I load planet.mozilla.org, FWIW. Clean profile.
status-firefox59: fix-optional → wontfix
status-firefox60: affected → wontfix
status-firefox61: --- → wontfix
status-firefox62: --- → fix-optional
status-firefox-esr60: --- → wontfix
planet.mozilla.org has markup like so:

  <script defer="defer" type="text/javascript" src="personalize.js"></script>

defer scripts are defined in the spec to run as soon as parsing of the HTML completes.  They do not block on pending stylesheet loads, unlike inline scripts.  personalize.js line 101 does:

    if (entries[i].parent.offsetTop > 0) {

which requests layout information, which forces layout to happen even though sheets are not loaded yet.

This might be a spec bug; running defer scripts before sheets are loaded is a bit odd.
Flags: needinfo?(annevk)
I filed https://github.com/whatwg/html/issues/3890. I won't have time to work on this for a while I think, but let me know if you think I should make it a priority.
Flags: needinfo?(annevk)
I found that setting font-size of <html> before CSS link causes FOUC on Firefox 63:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0

or

Mozilla/5.0 (Windows NT 10.0; WOW64; rv:63.0) Gecko/20100101 Firefox/63.0

See https://yanni4night.github.io/fouc-of-firefox63/

Chrome does too, but much less seriously.
The issue there is not setting the font size.   It's forcing layout to start via the documentElement.clientWidth access.  Once you do that, we have to start layout, of course, and it's happening before the CSS is loaded.

Seems to have gotten better for awhile but appears to have worsened in 66.0.2. Either that or I've just been used to it and started noticing it again.

Can really see it at https://bugzilla.mozilla.org/show_bug.cgi?id=1404468 (on 66.0.3 now).

Rather depressing that Chrome doesn't really have the issue that I can find.

(In reply to MarkRH from comment #63)

Can really see it at https://bugzilla.mozilla.org/show_bug.cgi?id=1404468 (on 66.0.3 now).

Rather depressing that Chrome doesn't really have the issue that I can find.

Argh, meant to paste: https://forums.warframe.com/topic/1083262-plains-of-eidolon-remaster-hotfix-2471/

(wish this had an edit option sometimes).

Depends on: 687441

There is still a FOUC on this webpage (for example) : https://fr.libreoffice.org/download/telecharger-libreoffice/
I don't know if there are subframes in it.

There are not. But what that page does have is:

   <script src="themes/libreofficenew/js/modernizr-2.6.2-respond-1.1.0.min.js"></script>

before all of its <link rel="stylesheet"> bits. That script forces rendering to start, because it does all sorts of layout-querying. After that, you will get unstyled content as content is parsed, until the sheets load.

Ideally that script would come after the stylesheet links; that's standard web development advice...

In particular, that script does:

  s.touch = function() {
            var c;
            return "ontouchstart" in a || a.DocumentTouch && b instanceof DocumentTouch ? c = !0 : y(["@media (", n.join("touch-enabled),("), h, ")", "{#modernizr{top:9px;position:absolute}}"].join(""), function(a) {
                c = a.offsetTop === 9
            }), c
 }

and calls that function, along with all the other detection functions is has.

After debugging for several hours, I found that if you add a dummy script right after your <body> tag, FF will only render the page when the CSS is loaded. Sigh.

This will not produce a FOUC: (except for fonts-loading)

<body>
<script>0</script>
...

FOUC in: https://wiki.mozilla.org/XUL:Lib_XUL

Apart from the webfont thing I mention in comment 44, I am not seeing FOUC here. If you are, please file a new bug with steps to reproduce? Chances are, it's due to something an extension is doing....

Still happens with version 69.0.1 in Windows 10 Pro (updated my Windows 7 system). I was able to get rid of the FOUC on some of my web pages by doing what was mentioned earlier by adding <script>0</script> after the <body> tag.

Depends on: 1520328
Depends on: 1586615

(In reply to claudio.silva from comment #33)

AdBlocker Ultimate definitely causes FOUC on a lot of websites!

Confirmed — that's definitely what was causing it in my case.

For my the culprit is the "Saka Key" extension.

Hi! I am from GItHub's frontend team and we are experimenting with <script defer> in <head> right after the <link> stylesheet tags, and we started to see pretty frequent FOUC in Firefox only, with a clean profile. It is not shipped yet (with FOUC being a blocker) so you can't see this on github.com.

All we did was moving the <script> tags from end of <body> to <head> and adding the defer attribute to them.

Based on the discussion here it seems like the Firefox team might already know what causes this? Please let us know if we can provide more information. The markup is similar to planet.mozilla.org, where I can also reproduce the FOUC.

The usual pattern is something like:

  • There's no <script> in the head blocking the parser and loaded stylesheets.
  • There's some <script> (deferred or doing something async) that queries layout while stylesheets are pending.

I don't know the cause for planet.mozilla.org in particular, but I can check tomorrow on a debugger, as I can reproduce it. If that's not the same thing for GitHub I guess I can ping you and ask for more info :)

Flags: needinfo?(emilio)

Ah, comment 58 had an analysis of this... So this is "just" https://github.com/whatwg/html/issues/3890, right?

So the TLDR is that some of your scripts are calling into layout-querying APIs, like offsetTop, etc...

I guess as a workaround an empty <script></script> after the stylesheets (or before the <script defer>s, basically) would prevent the FOUC, by waiting for pending sheets. I think that would effectively emulate the behavior that Blink (Chrome) uses today, which is blocking the parser on stylesheet loads.

Well, I lie, it needs not to be completely empty, so like: <script>/**/</script>.

So this would cause a FOUC:

<!DOCTYPE html>
<link rel="stylesheet" href="https://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=2&mime=text%2Fcss&text=body+%7B+color%3A+red+%7D">
<script defer src="data:application/javascript,onload = function() {alert('load: ' + getComputedStyle(document.body).color);}; alert('after: ' + getComputedStyle(document.body).color)"></script>

But this would not:

<!DOCTYPE html>
<link rel="stylesheet" href="https://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=2&mime=text%2Fcss&text=body+%7B+color%3A+red+%7D">
<script>/**/</script>
<script defer src="data:application/javascript,onload = function() {alert('load: ' + getComputedStyle(document.body).color);}; alert('after: ' + getComputedStyle(document.body).color)"></script>

Disclaimer: I know the above is quite a decent hack... I've been looking into FOUC-related bugs like bug 687441 recently...

Looks like there's spec agreement on the issue in comment 76 so maybe we should just change defer scripts to do that automatically before executing them...

Flags: needinfo?(emilio)

Still happens in 75.0 Mac OS both High Sierra (10.13.6) and Catalina (10.15.4). I created a sample page that, at least on my pc, exhibits the FOUC when the Developer Tools are opened (cache disabled, no throttling). The test page simply has a stylesheet loaded with some delay (6s).

  • This page: this page has FOUC
  • This page: this page doesn't show FOUC (it employs the empty script tag hack described before in this discussion).

Both the links work perfectly both on Safari and Chrome - even with Developer Tools opened (and cache disabled, as always).

Surprisingly, the same issue doesn't show up (at least, on my pc) if I manually erase the Web cache (from the preferences menu). Might it be somehow related to the developer tools?

(In reply to Stefano Cappellini from comment #80)

Might it be somehow related to the developer tools?

Yes, that's an issue with the devtools inspector. They update the layout of the page so that you can well, inspect stuff with the current styles. Firefox doesn't block the parser so there is actually content in the page. If you use the script hack the parser is blocked until the stylesheet comes back so the same happen, but the page is empty instead.

I'd file an inspector bug so that the devtools developers can consider changing it.

Depends on: 1726368

This still happens in Windows 11 Pro 21H2, on Firefox Release 100.0 64-bit (May 3, 2022).

using Firefox 100.0.2 64bit on Ubuntu. I have the impression that flashing unstyled content has massively increased in FF 99 or 100, with even twice switching i.e. unstyled-styled-unstyled-styled during page rendering. It's really annoying. I use add-on NoScript 11.4.5 so it may also be related to that, but with the Web in its current state I am reluctant to disable this extension.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 10 votes.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)

[Tracking Requested - why for this release]:

status-firefox117: --- → ?
tracking-firefox117: --- → ?
tracking-firefox118: --- → ?
tracking-firefox119: --- → ?

I'm having this problem in a new Drupal10 migrated site. I'm using Windows 10, Firefox 120 (64-bit). None of the online hacks are helping to resolve it.

(In reply to Helen from comment #88)

I'm having this problem in a new Drupal10 migrated site. I'm using Windows 10, Firefox 120 (64-bit). None of the online hacks are helping to resolve it.

Can you file a new bug with details on how to reproduce it? I'd be happy to take a look

Flags: needinfo?(pleasebuzzoff)

I'm seeing this on my site https://briantakita.me

As with Helen, none of the hacks fix the fouc. To reproduce

  • open https://briantakita.me
  • open the dev console
  • persist log messages
  • rapidly refresh the page
  • a fouc will happen ~ 20% of the time

I forgot a step. On https://briantakita.me, enable the dark theme by clicking the moon icon in the top right corner.

Hey Brian, can you make a screencast of this happening in Private Browsing Mode? I can't reproduce it on your site, and we should rule out any extensions.

I can reproduce what Brian describes, but I'm not at all sure it's related to the original issue here (in particular, I see a flash of light-mode content, not exactly unstyled content); so I'm going to file a new bug on it, which I'll link up here via see also.

(I captured Brian's issue in a Firefox profile in https://share.firefox.dev/3TQCXtL -- you can mouse across the screenshot track to see the dark rendering, and then brief light rendering on reload)
I suspect Brian's issue is actually a site bug, so i didn't file after all. I can reproduce it in Chrome as well; it's not Firefox-specific. From a quick look in devtools, it looks like the site's dark theme is implemented by having some JS dynamically set the data-theme attribute on the html node to either dark or light. It looks like that attribute is not initially present, so there's no theme established until that JS runs; and if I manually remove that attribute in devtools, then the site renders with the light theme.

So my guess would be that Brian's site is just dynamically checking for a dark mode preference (using JS) during or just-after pageload, and then adding that attribute dynamically -- and if the browser gets a chance to paint before that happens, then we get the flash of white. (Brian, if you think for some reason that paint should be impossible, or think there's a browser bug hiding there, feel free to file a new bug on your issue; but I think it's unrelated from the flash of unstyled content that this bug was about. Your issue here a flash of content as it currently exists, with the correct styles for that content.)

You need to log in before you can comment on or make changes to this bug.