Just started seeing this today - didn't know where else to park but in Fission, since it seems to be happening when I open a few tabs at once.

Profile: https://drive.google.com/file/d/1Mb5r2YdYSegbp9asVbTI0lH6TLqDguJI/view?usp=sharing

Just a profile of Firefox taking up 100% CPU across four cores and being only semi-responsive.

kmag suspects this to be related to extensions. NI for kmag to add more details here.

Asif, do you have NoScript installed? If yes, it might be related/similar to bug 1650305.

Henrik, no I don't have NoScript installed. I don't doubt that this is extension related, but I have had the extensions I have installed for a decent amount of time with no adverse effects - and I try to be careful about not installing bad add-ons.

Continuing to see massive slowness in today's build randomly. This time, I saw insane loading times, CPU use when loading https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=Desktop+Wireless+Network+Mini+PCI-E&_sacat=0&LH_TitleDesc=0&_osacat=0&_odkw=+Desktop+Wireless+Network+Mini+PCI-E+3+Antenna.

Profile here: https://drive.google.com/file/d/13ch2fGf2E2xPATmXDFg05dVfvBGtnEvK/view?usp=sharing

I had also gone ahead and cut down on my extensions to:

Always Right
Extension source viewer
Reddit Enhancement Suite
Twitter Container
uBlock Origin

about:support is attached in the next comment.

Trimmed my extensions further:

Always Right
Twitter Container
uBlock Origin

The issue seems to occur if uBlock Origin is enabled - surprising because this is normally a well-behaved extension and I have it working in default allow mode for most sites: https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-turn-off-uBlock-everywhere-except

26:08.39 INFO: Narrowed integration regression window from [74aed250, 4881bb77] (3 builds) to [df91fb44, 4881bb77] (2 builds) (~1 steps left)
26:08.39 INFO: No more integration revisions, bisection finished.
26:08.39 INFO: Last good revision: df91fb44b2d4bd8cf55cb2a5360094feb2c6ca6b
26:08.39 INFO: First bad revision: 4881bb77b5353c7a1509a7b7a868fc443fa9d722
26:08.39 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=df91fb44b2d4bd8cf55cb2a5360094feb2c6ca6b&tochange=4881bb77b5353c7a1509a7b7a868fc443fa9d722

Seems like this was regressed by bug 1606706.

[Tracking Requested - why for this release]: Poor performance with uBlock Origin.

(In reply to Asif Youssuff from comment #7)

The issue seems to occur if uBlock Origin is enabled - surprising because this is normally a well-behaved extension and I have it working in default allow mode for most sites: https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-turn-off-uBlock-everywhere-except

Seems like this was regressed by bug 1606706.

Asif, sounds like uBlock Origin is cause regardless of Fission being enabled or not. Please confirm.

Neha, I have been running the same profile and configuration with Fission disabled and I have not been able to reproduce the issue in the latest nightly build.

CPU usage sometimes spikes to 100% across all CPUs momentarily when restoring a tab from a saved session, but this doesn't last more than a few seconds; with Fission and uBlock Origin enabled, and after a few hours, these spikes last for minutes at a time and often results in Firefox crashing outright.

I was going to comment that, in the profile in comment 0, most of the overhead seems to be from the Textarea Cache extension, and to a slightly lesser extent Bitwarden. Though the comments since I was needinfoed seem to point to uBlock.

Either way, the different between the Fission-enabled case and the Fission-disabled case is probably just that we start more processes with Fission enabled, so there are more opportunities for idle cores to be used.

This is a bad regression though Kris - I know that we expect more memory use and processes in Fission, but I don't expect Firefox to lock up without any real recourse - especially if it had worked previously on the same hardware just a few days prior.

I also have 24GB of RAM - not really a small amount.

Is it expected that extensions in Fission may make Firefox impossible to use for longer periods of time or with many tabs open? Are there things that Firefox can do to improve the situation, or do extension developers have to work around this?

I ask because it is unclear whether you are saying that this is expected, or whether there is a problem with the way extensions are working with Fission enabled.

I'm not saying it's not bad, just that I don't think that Fission is the real problem here.

I don't really understand what's going on here. We didn't land anything recently related to content scripts and fission. If bug 1606706 was the cause, then I guess Bas could probably give some details here.

(In reply to Kris Maglione [:kmag] from comment #11)

Either way, the different between the Fission-enabled case and the Fission-disabled case is probably just that we start more processes with Fission enabled, so there are more opportunities for idle cores to be used.

Does that mean more cores == bigger opportunity for poorly written extensions to overload the CPU? Do we need to clamp timeouts and intervals more aggressively or something?

(In reply to Tomislav Jovanovic :zombie from comment #14)

(In reply to Kris Maglione [:kmag] from comment #11)

Either way, the different between the Fission-enabled case and the Fission-disabled case is probably just that we start more processes with Fission enabled, so there are more opportunities for idle cores to be used.

Does that mean more cores == bigger opportunity for poorly written extensions to overload the CPU? Do we need to clamp timeouts and intervals more aggressively or something?

No, it means the more processes, the more opportunities for main thread JS to peg a larger number of CPUs.

(In reply to Asif Youssuff from comment #7)

The issue seems to occur if uBlock Origin is enabled - surprising because this is normally a well-behaved extension and I have it working in default allow mode for most sites:

Could you please capture a perf profile with just uBO, and upload it to https://profiler.firefox.com/ ?

I re-enabled Fission and used Firefox today, resulting in a lockup of over an hour. Obviously, this made it impossible for me to run Firefox profiler to grab a profile, so I took mconley's advice and took a profile using perf.

You can find two profiles here: https://drive.google.com/file/d/1O1I6K7ghYZ-3nk0LZDbZvlfWe3IkIQsM/view?usp=sharing

Zombie, you want a profile of just uBlock Origin enabled and Firefox open? The problem isn't immediately evident - it shows up after an hour or so, and it generally gets to the point that Firefox makes it virtually impossible to capture a profile.

I can see that Firefox takes up 100% CPU when restoring pages momentarily, which is how I got the regression range that I ended up with, but I'm not 100% sure about that because I am not actually waiting for Firefox to lock up.

Let me know what you think about what/how/when to profile.

Tomislav,

I went ahead and took a profile while loading a CNN/Apple News article I received in an email (clicked a URL in another app that opened in Firefox).

I had other pages open already. I stopped profiling after the page stopped loading, but before my CPU calmed down (it was still at 100% across all cores) because waiting much longer makes profiles un-capturable.

https://drive.google.com/file/d/10GWyh51WF_bSN-Zfw4I-wkPmICHYk07Z/view?usp=sharing

My only enabled extension is uBlock Origin. I have Fission enabled.

Hope this helps!

I see lots of busy-spinning in event loops in background processes in that last profile, so I think this is also bug 1650629.

So I suppose one question is, what are these events that those background processes have in their idle queue? And are those events more likely to exist when uBlock Origin is installed?

ExtensionChild.jsm uses PerformanceCounters which uses DeferredTask which uses ChromeUtils.idleDispatch. Maybe that's how.

Here's an example process that's completely idle except for a DeferredTask: https://share.firefox.dev/2OaxZp1
This big profile contains more (hidden) processes that look similar. This is the profile from comment 18, but with some of the data removed to get it under 50MB.

I filed bug 1652048 on the background process ChromeUtils.idleDispatch phenomenon.