What hope do we have to get away from indeterminate xul:progressmeter for linux (ref comment 47) ?
... for all our dialogs. Unsure if same issue exists anywhere in calendar-land (see "see also" links)

xul:progressmeter was converted to html:progress. But looks like it's still reproducible at least on linux.
In scratchpad or console, do

document.getElementById("tabmail-container").appendChild(document.createElementNS("http://www.w3.org/1999/xhtml", "progress"));

... and check CPU usage. For me it goes to around 20% and stays there.

Can also reproduce on Firefox nightly. There in the Developer Tools | Console

document.getElementById("urlbar").appendChild(document.createElementNS("http://www.w3.org/1999/xhtml", "progress"));

The only difference is that there it jumps from listing Firefox to "GPU process" and back. It's still Firefox causing it.

There's only a few which are indeterminate and they're important for providing feedback to the user that something is happening. I think the best solution, if any, is to chase the toolkit people to fix their widget. FWIW I've not had a problem with this thing for years but it probably does use more CPU than necessary, about 6% of a CPU for me.

Thanks for the info.

To reemphasize the big problems: a) even at modest amounts of CPU, it sucks battery life, b) at modest amounts (above 5-10%?, I forget the range) it impacts responsivesness when getting new mail, c) to make it worse we have (or at least have had) situations where the progress meter lingers, and even sometimes never goes away due to other brokenness so the CPU usage can be continuous.

(In reply to Geoff Lankow (:darktrojan) from comment #58)

... I think the best solution, if any, is to chase the toolkit people to fix their widget.

So far after 10 years in bug 854093 that hasn't worked out so well for linux. (or do we need something else?) Does someone know stransky or do we have some other friend?

On the windows side this required aceman and our friend Neil in bug 658829 (ref bug 791535 comment 19). But even there we still might have an edge case per bug 658829 comment 97.

Thunderbird 68.2.1 on Linux, I can confirm that this issue still exists, with createElementNS() as given above, and the SMTP sending progress bar from bug 742697, and the IMAP loading progress bar in the status bar when switching between folders.

15-20% CPU usage.

How can you match the generated <html:progress> tag with userChrome.css ?

I'd like to style it differently to check how the performance behaves, or hide it, but I don't know how to match it, only its parent #statusbar-progresspanel.

Workaround:

I found that disabling the indeterminate progress progress bar is not enough; the spinning throbber in the tab is also responsible for CPU usage.

I'm using the below in my Thunderbird profile folder's chrome/userChrome.css to disable both, resulting in the 15-20% CPU usage disappearing:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

/* nh2: Progress bar CPU usage fix. */
/* For some stupid reason we can't match the html:progress that's the first child of this container.
   See https://bugzilla.mozilla.org/show_bug.cgi?id=562977#c61
   So we can't style the progress bar so that it does doesn't get shown only when
   indeterminate (which takes the most CPU), or style it to render faster.
   So for now we hide the entire parent container, thus getting rid of the progress bar entirely.
*/
#statusbar-progresspanel {
  display: none;
}

/* nh2: Tab throbber animations also take a lot of CPU; hide them.
   Unfortunately I didn't find a way to replace them by a static image.
*/
.tab-throbber[busy] {
  display: none !important;
}
.tab-throbber[progress] {
  display: none !important;
}

This user chrome is a real battery saver! Thanks! ...and the throbber in the mouse pointer still tells me if thunderbird is busy.

If I understand this right we now have 2 things that are rendered in the same thread and that use 100% of one CPU (indicated as 50% of the CPU power of a 2-CPU-System, 20% of the CPU power of a 5-cpu-system and 12,5% of the CPU power of an 8-cpu one) if they get the chance of doing so. ...or was the progress meter a Red Herring and it was only the throbber all along?

100% of one CPU normally doesn't indicate that something is amiss: The CPU could be asleep 99% of the time and be busy 1% of the remaining time. But the battery drain throbber+progress meter and generate seems to indicate that the CPU won't sleep while there is indeterminate progress...

Gunter, you could only apply the rule for #statusbar-progresspanel and check how the CPU usage is with only the throbber spinning.

I have already tested that.

• Only throbber: ~15-20% CPU usage
• Only progress bar: ~15-20% CPU usage
• Both throbber and progress bar: ~15-20% CPU usage
• Both disabled: no CPU usage

@Gunter: I measured CPU usage on Linux with htop, where the percentage is always relative to 1 core. 15% means 15% of 1 core. Using full 2 cores would show up as 200%.

100% of one CPU normally doesn't indicate that something is amiss: The CPU could be asleep 99% of the time and be busy 1% of the remaining time.

I don't understand this sentence. If the CPU is asleep 99% of the time, CPU usage in htop should show up as roughly 1%, not 100%.

(In reply to Niklas Hambüchen from comment #65)

I have already tested that.

• Only throbber: ~15-20% CPU usage
• Only progress bar: ~15-20% CPU usage
• Both throbber and progress bar: ~15-20% CPU usage
• Both disabled: no CPU usage

Strange that both together use the same CPU like when only one is active.

Please could you try

.tab-throbber[busy] {
  list-style-image: none !important;
}

Then I can see if the animated PNG is the cause of the CPU usage.

Yes, list-style-image: none !important; also fixes it.

Strange that both together use the same CPU like when only one is active.

I don't find that strange: Using either progress bar or animated PNG throbber, the screen now has to be drawn at many frames per second. Once you have to redraw, redrawing a bit more doesn't make a big difference.

Separetely: Also useful to know for posterity, the upgrade from Thunderbird 60 to 68 made the indeterminate progress bar a lot more jumpy (it looks like around 10 FPS while the original was much smoother) - but to my surprise that increased jumpiness still didn't reduce CPU usage a lot.

Richard, given the most recent bug comments, is a Thunderbird solution possible without addressing bug 854093?

I really wonder why even after 11+ years this is still not fixed and
reporters like me have been bugged multiple times with needless Needinfo requests?!?

As I wrote several times over several years at several places in this bug tracker:
The problem is easily reproducible with any TB version (meanwhile including 78.4.2.).

Again: just enter an IP address such as 1.2.3.4 as the server name/address.
Then try fetching emails. Until this timeouts,
the progress bar moves forth and back with significant CPU load (10% of one core on my current Linux machine).

In TB 78 we use now the HTML progressmeter. I hope this helps a bit.
I tried the FX approach with using a SVG as throbber but I see on my system no difference to the PNG throbber with 2% CPU.

For the throbber I could create a patch.

In TB 78 we use now the HTML progressmeter. I hope this helps a bit.

Your hope is not fulfilled.
I've just tried TB 68 in comparison with Tb 78 - and got the same 10% CPU load on both.
Again - why don't you IT professionals try out such things yourself?!?

I'm a voluntary contributor and don't need such comments. It's also not very helpful when I see only 1% difference when I test it.

One actually does not need to be an IT professional to see that for the given issue there is no improvement with FB 78.

For the throbber I filed bug 1695950.

This approach uses our colours to paint the progressmeter to also better fit with our themes. Or do you propose a different colour than --primary?

For the indeterminate state I used the approach FX is using on the download panel.

I hope this helps with the CPU usage. I can't say if it's better as for me it is still the same low value.

This patch implements your wishes.

I hope you have some cycles to check where the high CPU load comes from.

(In reply to Alessandro Castellani [:aleca] from comment #78)

little nit: this could benefit from a vertical-align: middle in the folder
props dialog, because the default value from toolkit is -0.2em, for
whatever reason.

I leaved it like it is. With vertical-align: middle it is too low, see screenshot, at least with normal scaling.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/fb607a0fb095
Make the progressmeter use the theme colors. r=aleca

(In reply to Alessandro Castellani [:aleca] from comment #78)

...
Let's leave this open so I can later take it and investigate the performance issue.

Is there a solution? Or should this be delegated to someone else?

This slipped between other bugs, thanks for the ping.

I'm not sure there's anything else to do here as I can't reproduce this issue anymore.
Tested on 91.5.1 and on my mac the usage remains around 5% without spiking anymore.
Also, if I'm not wrong, this is not a XUL element anymore but it's not a standard HTML progressbar.

Can anyone else still reproduce it?

I'll close the bug as we can't reproduce it.

(In reply to Richard Marti (:Paenglab) from comment #83)

I'll close the bug as we can't reproduce it.

Rather than Wontfix, it seems to me we should use WORKSFORME (for not reproducible using the STR) or Fixed via comment 80.