Recently I've noticed Firefox sometimes eating most of a CPU on the parent process main thread for no obvious reason, and the whole browser seems to be slow during this, especially if another application is using a lot of CPU. Profiling shows that it's repeatedly rendering/painting… something. And that something seems to be the Tree Style Tab sidebar when a tab is showing the loading animation (the dot moving back and forth) — it doesn't seem to happen when a tab isn't in that state, or when there's a tab that's loading but the sidebar for that window isn't shown. I'm not sure what component this belongs in; hopefully Graphics is close enough that it can be routed appropriately.

This sounds like it's probably actually an invalidation issue. I don't personally know what the 'Tree Style Tab Sidebar' is to be honest. Matt is probably a good person to see if this is invalidation related.

(Tree Style Tabs is a WebExtension that shows a replacement tab bar in sidebar available for any WebExtension to use.) Jed, what version of Tree Style Tabs do you have?

I wasn't able to reproduce this on OSX with the latest Tree Style Tab (2.4.16). Invalidation seems to be minimal (and painting the sidebar happens in the content process). What OS are you on?

I didn't see the OS question in comment #3, and that might explain a few things. This is on Linux, so WebExtensions would be in the parent process: https://searchfox.org/mozilla-central/rev/00dd116638001772fe354b081353b73f1cad405d/browser/app/profile/firefox.js#76-78 This is also using the default graphics settings, so, basic compositing. As for comment #2, I stopped using TST after filing this bug and I don't remember which version it was, aside from that it was the current version at the time. I left the needinfo because I was hoping to give a better answer than that by retesting, which brings us to: Trying the current TST (2.4.20), it does seem to still have this problem. Subjectively it doesn't seem quite as bad as I remember, but it might be worse with nontrivially nested tabs, which I don't have anymore. But the profiler shows a clearer difference: there's a string of 50-70 ms event processing delays (or more than that, if several tabs are loading at once), spent in nsLayoutUtils::PaintFrame; without TST there's some PaintFrame, but a lot less time spent there overall, and it mostly doesn't set off the angry red event processing delay UI in the profiler front-end. And here's something interesting I noticed: with a data URL that loads an image from a nonexistent host, the painting happens only for what looks like the first loop of the animation: https://perfht.ml/2Ghm2Yh The same thing without the add-on, for comparison: https://perfht.ml/2GlXZr1

This might be a duplicate of bug 1423398.