-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flash of unstyled content before author sheet loads #40
Comments
I think depending on your hardware, in order to get this to reproduce consistently, you might need to disable the pre-XUL skeleton UI. user_pref("browser.startup.blankWindow", false);
user_pref("browser.startup.preXulSkeletonUI", false); The UI details are saved in the windows registry too, I've had to clear them on many occasions at |
Hmmm. This sort of sounds like maybe the injection needs to happen before Either that, or indeed the sheet preloading step we do is the thing causing this. How exactly were you injecting your style? I just now tried with a modified However, this seems to make no difference - I can still see a short FOUC - usually at least, but not always. It's super inconsistent, sometimes I can't see the FOUC even with the preloading. This is with the two prefs you mentioned. |
Ah crap, I forgot my author sheet loader had that So, I just tried moving the script loading logic into the domwindowopened callback, and that didn't resolve it either. Even when using the stylesheet service over preloadSheet. I do know there's a slight delay with preloadSheet/addSheet vs. loadSheet, from what I was working on with FeatureCallout. But that was a much shorter delay, like barely a frame, that caused problems with transitions. I just did some testing on that and found I was also able to fix it by using That's rough. Maybe I need to find some way to make pre-xul skeleton UI work for me. It looks horrendous with my theme. For some reason it wants to use the light mode version too. Anyway, I think the reason I'm able to see the delay so consistently is because of the sheer amount of scripts and stylesheets I have, coupled with my session store holding like 20MB of 500+ tabs or something. So there's a whole lot of stuff holding up the event loop. |
How about if you run the style injecting directly in the observer callback? Basically run this: if(this.styles.length > 0){
const disabledScripts = getDisabledScripts();
for(let style of this.styles){
if(!disabledScripts.includes(style.filename)){
ScriptData.tryLoadScriptIntoWindow(style,aSubject)
}
}
} Immediately before line 568 here (and remove lines 443-450). I mean aren't observer callbacks pretty close to synchronous, whereas event callbacks might fire at next event loop? I have really hard time reproducing the FOUC consistently so I can't really say if this is any better. I think it might be fine to make the loader inject author styles at that time if that seems to work better. |
That's the same thing I did last night. No dice. I'm sure it does make some improvement (how could it not, moving from DOMContentLoaded to domwindowopened), but just not a noticeable amount for me. However, it just occurred to me I was testing all this with a modified version of my script, not with actual stylesheets. And that is pretty close to the end of the list since its name starts with |
With the preloadSheet/addSheet method, there seems to be a flash of unstyled content, I'm guessing because some part of the process is not blocking. It's easy to see with some drastic style like
I noticed it with a style that allows tabs to flex to the full window width:
I've seen this before while working on this, so I guessed that it's the method. It can't be fx-autoconfig itself, since that's what I've been using to load my stylesheet loader (that uses
loadAndRegisterSheet
currently), which doesn't have a FOUC. Also, if I usewindowUtils.loadSheetUsingURIString
, it also seems to block loading, eliminating the FOUC. Which makes sense based on its code comment.I guess there may be some tradeoffs with using one of these methods. But it can make sense for stylesheets that impact the browser appearance immediately on startup to prefer synchronous loading over any potential performance benefits. CSS loads synchronously by default in most applications, so that might be more expected. Though it could also be cool to have a
@defer
tag or something.The text was updated successfully, but these errors were encountered: