User Agent: Mozilla/5.0 (Windows NT 6.1; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Downloading one or more files - make downloads visible as a tab

Actual results:

CPU usage on both cores goes up to 66% (older notebook with Windows 7, Firefox 93) - minimizing Firefox or changing to another tab: CPU usage down to 1%.

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

Hi Theo,

I tested this on Firefox Nightly 95.0a1 and couldn´t reproduce it.

What kind of files and from wich website were you downloading when you got this issue?

Can you please attach your about:support information?

Also, it would help us if you can provide a memory report from about:memory, here are the steps for you to get it:

• Wait until Firefox is consuming a large amount of memory
• In the URL bar type about:memory and press enter
• Click ""Measure and save"" (optionally with ""anonymize"" checked to hide URLs, although this will likely make it more difficult for us to figure out which site, if any, is causing the leak)
• Save the memory report somewhere
• Attach the report to this bug

Also it would help us a lot if you could reproduce this issue on our latest Nightly build, it can be downloaded from here: https://nightly.mozilla.org/

Then capture a performance profile using
https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html
https://perf-html.io/

Please also note that this add-on works only on FF Nightly, so that means you need to be able to reproduce the issue on Nightly first.

Thanks,

Estanislao

Dear Estanislao,

here is the about:support data.

(edit: moved to attachment)

Report about:memory also attached. Good luck.

Hey florian, cc'ing you in case this is interesting from a power-usage perspective.

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Profiling shows that the downloadProgressSlideX CSS animation runs for the entire duration of the download: https://share.firefox.dev/3nf2aOa (well, actually the animation stops when about:downloads is no longer the foreground tab: https://share.firefox.dev/30sztV6)

The CSS code sets this animation at https://searchfox.org/mozilla-central/rev/3c8a7970944daaf917b547dffc0790bcd37cadc1/browser/themes/shared/downloads/progressmeter.inc.css#72,85 with the .downloadProgress:indeterminate::-moz-progress-bar { selector.

Emilio, any idea of why this animation keeps running even when the progress bar is no longer in an indeterminate state?

Fwiw, I think this bug also exists in the downloads panel, but I was kinda hoping that the work in progress patch in bug 1714846 would make the issue irrelevant. However, in about:downloads the bug will still exist even if bug 1714846 is fixed.

I'm surprised the animation works at all in ::-moz-progress-bar tbh. But I took a look and have a fix.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #10)

But I took a look and have a fix.

Thank you very much!

Hi Theo,

In bug 1742393, I believe we may have fixed this issue. Are you still seeing high CPU usage on about:downloads?

Well, dear Mike,

as we've reached v110 - the bug no longer exists. Thank you for your efforts.

Thanks, Theo!