The dynamic CSS load system that we're using creates a 'flash of unstyled content' when the console is first opened.
I can think of 4 options: 1. Include the CSS in browser.xul (i.e. the original solution) Dao suspected this would cause performance problems, but we didn't ever estimate the scale of the problem. This is very simple to implement. 2. Find some way to 'pre-heat' the CSS loading. The load already happens at the start of an animation, so it's hard to imagine how we can improve on this enought 3. Use an iframe. This option has previously been dismissed as far too complex and requiring re-writing too many tests. (See bug 688981) 4. Alter the CSS loading system to a faster one. I don't get why it's so slow. Maybe there is a better way. Dao - can you give us any numbers or even estimates as to why we shouldn't do #1? It seems like the obvious solution right now.
Performance isn't a concern as long as the stylesheet doesn't contain slow selectors. The primary concern with option 1 is that random modules pushing their stuff into the browser window's DOM tree is messy. browser.xul and tabbrowser are complex enough. I also don't really want to be the gatekeeper for your stylesheets, but I need to keep doing strict reviews as long as you style browser.xul. I don't understand why an iframe would be complex. Tests should use helper functions that abstract the differences (e.g. due to the iframe loading) away.
Moving GCLI bugs to Developer Tools: Console. Filter on 'baked beans are off'.
6 years ago
Triage. Filter on PEGASUS.
5 years ago
GCLI Triage. Fixed with the closing of bug 720641