Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:86.0) Gecko/20100101 Firefox/86.0 ID:20201218095607

While working on a webextension I wanted to test it out in my Nightly profile and loaded it by using about:debugging. I actually left the tab open (running in background) and noticed a bit later somewhat unusual CPU spikes up to 70% of the parent process while Firefox was idle.

Here a recorded profile: https://share.firefox.dev/3nHZ5ny

This all seems to be related to errorLoggingMiddleware, and each time such a spike happens there is more memory allocated which isn't released afterward.

Thanks for the report and profile!

Note that even though errorLoggingMiddleware shows up, it's just because it's the first middleware to be invoked when an action is triggered. The time is not actually spent in this middleware. It is most likely spent re-rendering the page. It would help to know ow many debug targets were visible on the page when this happened.

If you used your nightly profile, I imagine there might be a lot of registered workers (eg on my profile I have 50 service workers registered, and they get re-rendered quite frequently, due to the nature of our service worker implementation).

(Regarding the leaked memory, I think I had another bug with a WIP patch to fix a leak, will try to find it to see if it's related).

Henrik: Can you check how many debug targets (esp service workers) are visible in about:debugging on your Nightly profile?

I have 97 Service Workers listed but interestingly right now I do not see a high CPU load. I will keep an eye out.

Note that if rendering would be involved nothing should actually be drawn given that it was a background tab, and it would be visible in the GFX process. Maybe this is related to the framework that is used here and the DOM gets unnecessarily updated?

Thanks for the info!

I have 97 Service Workers listed but interestingly right now I do not see a high CPU load.

The service workers UI is updated every time the list of workers changes (a worker is created/destroyed/...). So a simple web worker starting / stopping will trigger an update (won't get into the details of why we have this inefficient approach here, but I can give more details if needed). Maybe when you initially had the issue, there were many worker updates, triggering a lot of work in about:debugging.

Maybe this is related to the framework that is used here and the DOM gets unnecessarily updated?

We use React for about:debugging. We haven't implemented any visibility handler for about:debugging, but we could add one to skip rendering when the tab is not displayed. See the VisibilityHandler helper added in DevTools for some of our React panels https://bugzilla.mozilla.org/show_bug.cgi?id=1399242

(In reply to Julian Descottes [:jdescottes] from comment #1)

(Regarding the leaked memory, I think I had another bug with a WIP patch to fix a leak, will try to find it to see if it's related).

I was thinking about https://bugzilla.mozilla.org/show_bug.cgi?id=1617015, but it doesn't seem related. What you described here could be a leak occurring when re-rendering the runtime page. I'll see if I can isolate this and reproduce the leak.

I actually wonder if that was some kind of side-effect with NoScript. As I have just seen on bug 1677393 comment 9 there was a fix in version 11.1.7 of NoScript as released on Dec 22nd that was for: Optimize serviceWorker tracking for heavy tabs usage.

Not sure what that means, but it would underline why I cannot see the behavior anymore.

Just tried with 11.1.6 and also wasn't able to reproduce it. So no, the NoScript fix is unrelated here. Also about:debugging is a privileged site, so NoScript won't even run.

It just happened to me again. I had this tab open in a separate window (in the background but the tab showing) of Nightly and didn't use the window at all for more than a day. The base CPU load of the main process (main thread) of Firefox was always around 30%. Closing the tab dropped the base CPU load by around 15%!

Here the profile with the tab open: https://share.firefox.dev/2KV11uT

I don't necessarily think a leak is involved here. We might just implement a visibility handler for about debugging.