Downloads icon in toolbar still slows download operations down a lot with >100 windows open.
Categories
(Firefox :: Downloads Panel, defect, P3)
Tracking
()
| Performance Impact | ? |
People
(Reporter: tim.w.connors, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Steps to reproduce:
Open 119 firefox windows with a few tabs each (or just 35 if that's all you care to do; becomes much more likely to happen if you save sessions for restarts). Leave downloads button enabled in toolbar. Try to save a download - be it a webpage or an image. Best to try download a file that will take a long time to download, to best demonstrate the problem. The storage you're saving to doesn't appear to matter - I was saving to a fast enterprise class SSD.
Now remove that download icon from toolbar, clear cache if necessary (or just download a different object), and download and save an object.
Actual results:
Firefox becomes extremely unresponsive for duration that download is in progress, if there is a download icon present in the toolbar. You'll notice the download icon changes to a progress meter. You'll notice each of the other windows are also displaying each and every update to that toolbar icon (and obviously most of your 118 other windows aren't even visible on the screen, but they're obviously also updating their download progress icon). If you're downloading a 1GB movie file, you can expect the entire firefox session to be unusable for the entire duration of that download. Other browsers with similar numbers of windows open do not have this problem.
Whereas once you remove the download icon from the toolbars, save becomes nearly instantaneous again, just like on a fresh profile.
Expected results:
I wouldn't expect even updating 119 icons would be a particularly expensive mechanism on a modern computer, but given everything is javascript, some effort could be made to ensure that only a reasonable number of these icons are being updated at a single time rather than all of them, including on undisplayed windows. Perhaps only update the 5 most recently displayed windows (or maybe even only on the window who "owns" the download). Perhaps only update them a maximum of once every 1 second, not continuously for the entire duration of the download.
|
||
Comment 1•1 year ago
|
||
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.
|
||
Comment 2•1 year ago
•
|
||
We've tried to fix this already (bug 1781090) but it depends on occlusion detection of windows (ie knowing those windows aren't painting on the JS side). I don't know how well that works on Linux - it may depend on use of wayland or otherwise. Have you tried a non-ESR version of Firefox? (The fix in bug 1781090 landed in 110, the current release version, and comment 0 suggests you're on ESR 102.)
(In reply to Tim Connors from comment #0)
Perhaps only update the 5 most recently displayed windows (or maybe even only on the window who "owns" the download).
This is a reasonable suggestion but not straightforward, because there may not be a window that "owns" the download (webpages at some point at least loved opening a temporary window to start a download, and then closing that window again), and popup windows don't have a downloads indicator at all. Downloads can also be initiated by background windows, and notifications should probably still happen on foreground windows in that case (so you don't just miss that this is happening).
Still, perhaps we could do still better here.
Perhaps only update them a maximum of once every 1 second, not continuously for the entire duration of the download.
Doing this but still having a smooth animation of progress (that is strictly progressive, ie doesn't estimate where we'll be in 1 second and then go "backwards" when we don't actually download those bytes, which would also be confusing for users) is also not trivial.
|
Reporter | |
Comment 3•1 year ago
|
||
Yes, that was under firefox ESR 102, using Debian/stable. I just tried firefox 110.0.1 through a snap install. It appears to suffer from the same issue.
|
|
||
Comment 4•1 year ago
|
||
(In reply to Tim Connors from comment #3)
Yes, that was under firefox ESR 102, using Debian/stable. I just tried firefox 110.0.1 through a
snapinstall. It appears to suffer from the same issue.
This is sort of surprising. What window manager / desktop environment / gtk/wayland setup do you use? And are the [other] windows all maximized, and/or fully hidden ("occluded") by other windows, or are they minimized, or...?
|
|
Reporter | |
Comment 5•1 year ago
|
||
FVWM window manager. All other windows are non-minimised, but most are off the screen on other virtual pages/desktops, so not visible.
|
|
||
Comment 6•1 year ago
|
||
(In reply to Tim Connors from comment #5)
FVWM window manager. All other windows are non-minimised, but most are off the screen on other virtual pages/desktops, so not visible.
Emilio, do you have any idea how to find out whether the occlusion detection is working in this situation and/or if not, why not?
|
||
Comment 7•1 year ago
|
||
IIRC X11 doesn't track occlusion properly, that's bug 1693513. Wayland does tho.
Description
•