Steps to reproduce:

Thunderbird should not impose CPU load when it is actually in idle state waiting for network response or for user input. Currently animated progress bar in the status bar may cause:

• CPU load high enough to make fan noise significantly louder,
• battery drain.

Infinitely oscillating gradient is not friendly to power-saving. Besides thunderbird enough web sites have the same problem due to their "loading" placeholders.

I am already tired with Bug #1753195 but even after it (I hope) will be completely fixed, there will be completely valid cases such as waiting for SMTP password prompt when progress bar is in active state. A user may be distracted by something more urgent making time interval with progress bar quite long.

There is no specific steps to reproduce, just regular activity or the bug mentioned above.

Actual results:

Progress bar appears in the status bar and becomes primary cause of CPU load. Thunderbird may doing nothing but waiting. At the same time e.g. CPU load due to an HTTP server sending a file at several Mb/sec is unnoticeable.

Some eye-candy UI elements are sometimes referred to as bells an whistles. After update from thunderbird-78 to thunderbird-91 I get the progress bar that is literary a whistle due to fan noise.

Expected results:

• Appearance of progress bar that does cause noticeable CPU load
• Limited count of animation iterations (it may be updated by progress report when thunderbird is really performing some lengthy task)
• When thunderbird waits for user input, CPU load should be zero, message in the status bar and static image of progress bar may help to make such state clear for users.

I would consider this a duplicate of the already reported issues/bug(s) it attempts to resolve.

(In reply to Wayne Mery (:wsmwk) from comment #1)

I would consider this a duplicate of the already reported issues/bug(s) it attempts to resolve.

I consider current appearance (design) of progress bar as a regression in respect to earlier versions. That is why I created an issue independent of code paths that show or hide progress bar.

In thunderbird-78 and earlier I sometimes noticed progress bar when no active tasks expected. I did not bother. There are more minor bugs sometimes annoying, but not enough to consider migration to another mail and news application. With update to thunderbird-91 it became a pain due to increased fan noise (and I do not see any reason to add CPU load by a useless animated image).

The code related to tracking state of progress bar is fragile. Ping Chen (see the Bug #1753195) is already tired despite even the case from the original report has not fixed yet. There are some improvements but I have no idea how many similar bugs are still there.

There are cases when thunderbird waits for input from user (password prompt) but incorrectly shows that some action is in progress by oscillating image. Are there bugs to change such behavior?

My point is that visual representation of progress bar often provides wrong feedback giving impression of some activity despite internal idle state.