User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Starting a download with 30 plus upwards windows open. This issue can be felt moderately with perhaps 20 windows onwards, and severely from 50 windows onwards. Nowadays, Firefox completely and utterly stalls my whole computer while I download anything at all.

Downloading something in a single private browsing window, as a point of comparison, the download animation has no effect on the performance of the browser.

This is also a problem with any and all add-ons that have updating icons (number indicators, etc.) in the menu toolbar - the common factor being that the browser updates the UI in each window, causing the stalling/freezing effect.

Actual results:

The download meter animation frames updating stall the browser when the user has lots of windows open.

Every time the download progress wheel icon frames are updated, the entire browser UI stalls completely, apparently updating every window simultaneously, creating massive and constant stress on the browser UI.

Once each window has updated the animation frame, control of the UI returns for a moment. As soon as the download progresses enough for the icon to be reupdated, the browser completely freezes again.

Expected results:

The issue has clearly to do with the animation being updated simultaneously in every window, not just the visible one(s).

To save resources, the browser should update the animations in just currently visible window(s), and update them iteratively as the user switches back and forth.

The Bugbug bot thinks this bug should belong to the 'Firefox::Downloads Panel' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

If this happens with other things besides downloads, it sounds like a graphics issue.

Maybe similar to my bug 1778214?

I think you meant bug 1779559 rather than bug 1742797 for the see also field.

Hey kingofthe@slowdays.org, would you mind capturing a general performance profile using the built-in profiler when this slow down happens?

https://profiler.firefox.com/

(In reply to Florian Quèze [:florian] from comment #4)

I think you meant bug 1779559 rather than bug 1742797 for the see also field.

No relation here to bug 1778214?

(In reply to Arthur K. [He/Him] from comment #6)

(In reply to Florian Quèze [:florian] from comment #4)

I think you meant bug 1779559 rather than bug 1742797 for the see also field.

No relation here to bug 1778214?

It's hard to say for sure until we see a profile for this bug, I would currently say no, because comment 0 here mentions that the problem gets worse when there are more windows, which points at issues with the progress animation in the downloads toolbar icon happening in every window.

https://share.firefox.dev/3BKhsSy

This is me downloading a small .jpg after turning on the Profiler.

Using the Profiler was a curious exercise, because pressing the Profiler button too triggers an animation (the colour of the icon changes) and this too stalls the browser for some seconds. Similarly, merely moving the Profiler icon from my Overflow Menu to the Toolbar froze the browser for a few seconds.

To reiterate, for me, downloads have no discernible adverse effect on performance as long as they're run in a private window (i.e., there is only one animation playing). The bug is definitely about updating and polling the toolbar.

(In reply to KotW from comment #8)

https://share.firefox.dev/3BKhsSy

This is me downloading a small .jpg after turning on the Profiler.

Using the Profiler was a curious exercise, because pressing the Profiler button too triggers an animation (the colour of the icon changes) and this too stalls the browser for some seconds. Similarly, merely moving the Profiler icon from my Overflow Menu to the Toolbar froze the browser for a few seconds.

To reiterate, for me, downloads have no discernible adverse effect on performance as long as they're run in a private window (i.e., there is only one animation playing). The bug is definitely about updating and polling the toolbar.

Thanks a lot for the profile! Here's what I see in it:

• the download animations in the toolbar when starting your download blocked the browser for 900ms: https://share.firefox.dev/3P8NEST That seems very long for a 267ms animation. It's the downloadsButtonNotification animation triggered from https://searchfox.org/mozilla-central/rev/5644fae86d5122519a0e34ee03117c88c6ed9b47/browser/components/downloads/content/indicator.js#473
  Gijs, it looks like this this.showEventNotification("start"); call is not throttled by your patch for bug 1781090, but maybe it should?
• the profiler icon changing also caused activity for about 900ms: https://share.firefox.dev/3Qtefee We should probably block updates of that icon in occluded windows. That shouldn't block processing user events.
• it looks like user events were blocked for about 6s soon after starting the profiler, waiting for an answer to sync IPCs. And after that a new GPU process starts. So if I had to make a guess about what happened, I would say it's likely that the GPU process crashed when the profiler started in it, and then it took the parent some time to detect it and restart a new one. That's probably what you felt as "stalls the browser for some seconds".
• after restarting, the GPU process was pretty busy for about 10s, painting ~100 windows.
• showing the file picker was also pretty slow, looks like it took at least 3s, but that's code in Windows, not in Firefox.
• the GPU process doesn't seem to get as much CPU time as it would like, delaying everything. But that's strange with a machine with "⁨⁨4⁩ physical cores⁩, ⁨⁨8⁩ logical cores⁩", maybe you were doing something else CPU intensive in another application? That would explain some of the slowness, but I'm not sure that's a good explanation as the profiler seemed to have no trouble sampling at a consistent rate.
• there's a GMP process, decoding a DRM'ed video, probably also taking some CPU resources away from the rest.
• it looks like some WebExtensions play a role in the slowness, for example one network request was delayed by more than 6s. But that might be just a side effect of the GPU Process being blocked rather than the extension's fault.
• I'm not completely sure how you configured the profiler (maybe that was the "Web Developer" preset?), but not having the "stackwalk" feature and having so few processes shared makes it hard to interpret the profile. If you could capture a profile with the "Firefox" preset (and maybe even add the "IPC Messages" feature) and then when sharing check the "Include hidden threads" checkbox (and also the "Include extension information" checkbox if there's nothing you would rather keep private in the list of add-ons you are using), the profile would be way easier to read.

Thanks for the quick response! This has been a worsening issue for me for years, so I'm happy to be of some assistance.

https://share.firefox.dev/3oYLyud

For this one, I've set the Profiler to the "Firefox" preset, and turned "IPC Messages" on. I've kept the extensions checkbox off for now - many of them do exhibit similar lag in instances where their icons update, but I don't believe them to be the overall culprit here. Unfortunately, I was also unable to use "Include hidden threads", because that takes the upload over 100mb, causing the profile to be rejected by firefox.com.

For the duration of the process, I've also closed down almost all my other applications, though they were all just small desktop tools and clients (Steam, Skype, etc.) to begin with, and Firefox is what stalls them and the desktop UI - not the other way round. This issue happens consistently, for any and all downloads that trigger the UI, whether any applications are running in the background or not.

As for video playback, I'm sure to have some paused or stopped Youtube tabs open in some of the many open windows, but 90 % of my all tabs overall are unloaded (i.e., not reloaded when I restart the browser). This, I assume, explains the bloated hidden threads size too.

There's a lot to say about the capture itself, which was a download of a 500mb file. It took about 20 seconds longer for the download manager UI element to update to "completed" after the download itself had already completed half a minute ago. It's amusing to see the icon struggling to go thru the motions in the stalled UI even though the download is already done.

Seems like the screenshot functionality of the Profiler is really something on such a setup, too - my overall memory usage popped from about 20gb to 27gb while the profiler was working. The browser also stalled for a minute after I stopped the Profiler, and similarly it took minutes to import the profile.

(In reply to KotW from comment #10)

Thanks for the quick response! This has been a worsening issue for me for years, so I'm happy to be of some assistance.

https://share.firefox.dev/3oYLyud

Thanks for the new profile! Nothing strange in the GPU process and no GMP process this time (but maybe it's in the hidden threads?). Also no obvious slowness due to add-ons.

The first thing I noticed is that you have one content process (pid: 38480) taking 100% of a CPU core, and it has apparently been doing so for a bit more than 24h! Without seeing the urls I can't say for sure what's happening there, but I strongly suspect it's a google website where you would be experiencing bug 1755864.

You might find about:processes useful to identify tabs taking too much resources, and kill their process if needed.

As for video playback, I'm sure to have some paused or stopped Youtube tabs open in some of the many open windows, but 90 % of my all tabs overall are unloaded (i.e., not reloaded when I restart the browser). This, I assume, explains the bloated hidden threads size too.

The selected tab of every window is loaded, so that's probably already many tabs that are loaded and have a content process attached. Again, about:processes can help to see what's running.

Seems like the screenshot functionality of the Profiler is really something on such a setup, too - my overall memory usage popped from about 20gb to 27gb while the profiler was working.

If you are not planning to include the screenshots when sharing the profile, you can disable the screenshots feature from the profiler settings before you start the profiler. That should reduce a bit the profiler overhead.

The browser also stalled for a minute after I stopped the Profiler, and similarly it took minutes to import the profile.

That's not unexpected for a profile of this duration. The size limit for the upload is currently 50MB. You could get a smaller profile by just capturing a shorter period of time.

Anyway, other than the content process taking 100% of a core, in this profile we see the downloadsButtonNotification animation played in every browser window (I already mentioned that in comment 9), taking about 1.5s. And we see the download progress being updated in every window too (there's a fix in progress for that in bug 1781090).