Thunderbird hogs CPU while waiting for master password

[Benkinooby]

1) Ubuntu 12.10

2) Package: thunderbird
Architecture: i386
Version: 17.0.7+build1-0ubuntu0.12.10.1

3) expected behaviour:
* I start Thunderbird
* Thunderbird idles at less than 1% CPU usage (I don't let it fetch mails at start up)
* I click "Get Mail" and Thunderbird asks me to enter the master password.
* While Thunderbird is waiting for me to enter the master password, it should use the same amount of ressources as it does when ideling.
* After entering the master password, Thunderbrid fetches the mail and then idles at less than 1% CPU usage

4) current behaviour:
* I start Thunderbird
* Thunderbird idles at less than 1% CPU usage (I don't let it fetch mails at start up)
* I click "Get Mail" and Thunderbird asks me to enter the master password.
* While Thunderbird is waiting for me to enter the master password, Thunderbird hogs up to 40% of my CPU until the master password is entered.
* After entering the master password, Thunderbrid fetches the mail and then idles at less than 1% CPU usage

5) additional info:
I use three POP and one IMAP account.

[toralf (toralf-foerster)]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120907154448

Steps to reproduce:

started Thunderbird and forgot to type in the password

Actual results:

4-core CPU is up to 100%, fan is very noisy

Expected results:

a (milli)sleep in that source code loop to keep my ThinkPad quiet and cool

[toralf (toralf-foerster)]

maybe a blinking task bar window should be enough for forgetful people like me.

[Vseerror (vseerror)]

I see this with imap account

[Vseerror (vseerror)]

steps
1. start thunderbird
2. click on imap account folder where it is set to check for new messages at X interval and does NOT have account password saved.

results:
password prompt comes up
progress meter spins

not 100% reproducible after first occurrence, unless you restart thunderbird

[Acelists (acelists)]

OK, this is a good reproducible case, I can see it.

[Acelists (acelists)]

So in case of this statusbar scrollbar it is defined in mail/base/content/mailWindowOverlay.xul id="statusbar-progresspanel". The progress is updated in mail/base/content/mailWindow.js::updateProgress . From what I could see we DO NOT call this function often (only once at beginning and once at finish of the progressbar. It is an "undetermined" mode progress bar so it spins by itself once started. It seems the internal XUL implementation of the progressmeter widget is not very efficient. The implementation is in mozilla/toolkit/content/widgets/progressmeter.xml <binding id="progressmeter-undetermined">. There seems to be a tight loop calling mozRequestAnimationFrame() without any throttling (if the mozRequestAnimationFrame does not have any).

According to http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html this is the intended operation and the application (FF/TB) determines how many frames per second it generates.

So I am not sure what we can do here.

Any anybody check if the progressbar in Firefox is also that CPU heavy?

[Acelists (acelists)]

Moving to Frontend until we determine if this shouldn't actually go into Toolkit. But Security component was way off.

[Bzbarsky (bzbarsky)]

mozRequestAnimationFrame throttles to run no more than at 60Hz. That's its whole purpose.

[Acelists (acelists)]

Is it possible to request even lower framerate? It seems it is quite CPU heavy. The reporter talks 100% of 4-core CPU. But in my testing a tiny progressmeter took 40% of 1 core on a 3Ghz machine. Still a lot.

[Bzbarsky (bzbarsky)]

> Is it possible to request even lower framerate?

Not easily, no. However the callee can of course throttle lower by just checking the call time, which is passed to the method...

[Acelists (acelists)]

Thanks.
So I modified the binding to only set the spacer properties 3x per second but the CPU usage is not that much down. There must be some other slowness.

[Vseerror (vseerror)]

Do the profiler links in Bug 562977 reveal anything for you?

[Neil-httl (neil-httl)]

(In reply to aceman from comment #5)
> Any anybody check if the progressbar in Firefox is also that CPU heavy?
Depends on the OS; on the Mac it's drawn natively, on Windows there were plans but they didn't come to fruition. It takes up lots of CPU on my Linux system though.

[Bzbarsky (bzbarsky)]

> Do the profiler links in Bug 562977 reveal anything for you?

Mostly painting, no?

[Acelists (acelists)]

Neil, yes, the original report and also my tests are from Linux. But there is also a noticeable load on Windows XP, like 40% of 1 core of a Core 2 Duo CPU at 2Ghz.

[Vseerror (vseerror)]

see bug 602126 / Bug 602964
Is this the same presentation method?

[Acelists (acelists)]

No idea, but with TB26 I still see the high CPU usage while a progressbar is spinning.

[Vseerror (vseerror)]

(In reply to <email address hidden> from comment #12)
> on Windows there were plans but they didn't come to fruition. It takes up lots of CPU on my Linux
> system though.

is there a bug# for these plans?

[Vseerror (vseerror)]

matti do you see this on SM?
iirc you run all 3 platforms - what numbers do you get?

[Neil-httl (neil-httl)]

(In reply to Wayne Mery from comment #17)
> (In reply to comment #12)
> > on Windows there were plans but they didn't come to fruition.
>
> is there a bug# for these plans?

Yes, I ended up chasing bug 658829 myself and got the patches landed (and also bug 729649 for good measure), so progress meters don't use XBL animation any more on Windows. (I'm not sure what the name of the animation they use now is called, or whether it uses more or less CPU.)

[Bugzilla-tf (bugzilla-tf)]

I currently can't test on Linux due to my limited time

[Acelists (acelists)]

Does anybody still see this? Win TB32, in Win XP (as in comment 14) I can't see the high CPU usage. Via DOM Inspector, in TB main window (chrome://messenger/content/messenger.xul) I found <statusbarpanel id="statusbar-progresspanel"> where I set collapsed="true" to uncover the status bar progress meter. Then in <progressmeter id="statusbar-icon"> I set mode="undetermined". The progress bar began spinning without much CPU usage. So the progressbar alone doesn't seem to be the culprit. If we can find the CPU usage in other scenario, maybe something else is contributing to it.

[Neil-httl (neil-httl)]

Bug 658829 changed the way undetermined progress meters were painted on Windows from an XBL implementation to a native implementation. Linux still uses the XBL implementation for undetermined progress meters though.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Vseerror (vseerror)]

*** Bug 1301997 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

(In reply to <email address hidden> from comment #22)
> Bug 658829 changed the way undetermined progress meters were painted on
> Windows from an XBL implementation to a native implementation. Linux still
> uses the XBL implementation for undetermined progress meters though.

The linux side is bug 854093.

[Wls220spring (wls220spring)]

I can't reproduce this using Ubuntu Thunderbird 52.3.0 on Ubuntu. My 3-core CPU is at 12%

[Paul White (paulw2u)]

Still an issue using Ubuntu 18.04.1 and Thunderbird 52.9.1.
htop reports around 40% CPU usage
3 IMAP and 1 CalDav accounts
Ensured mail not being checked at start-up
Will report upstream and link report ID

[Vseerror (vseerror)]

*** Bug 1490245 has been marked as a duplicate of this bug. ***

[Paul White (paulw2u)]

Updating Mozilla bug, original was a duplicate

[Paul White (paulw2u)]

Benkinooby contacted me direct to advise he is now using Gentoo where he doesn't see this issue.

[PeterPall (peterpall)]

@WaltS48: A 3 core with Hyperthreading has 6 logical cores. 12% is 100% of one of the logical cores your CPU provides.
@aceman: On MS Windows I don't know. But on Linux if thunderbird is waiting for input from keyboard or the network it still uses a full CPU core.

[Vseerror (vseerror)]

(In reply to :aceman from comment #21)
> Does anybody still see this? Win TB32, in Win XP (as in comment 14) I can't
> see the high CPU usage. Via DOM Inspector, in TB main window
> (chrome://messenger/content/messenger.xul) I found <statusbarpanel
> id="statusbar-progresspanel"> where I set collapsed="true" to uncover the
> status bar progress meter. Then in <progressmeter id="statusbar-icon"> I set
> mode="undetermined". The progress bar began spinning without much CPU usage.
> So the progressbar alone doesn't seem to be the culprit. If we can find the
> CPU usage in other scenario, maybe something else is contributing to it.

for linux see Gunter's bug 562977 comment 55

[Acelists (acelists)]

Progressmeters were replaced with a different implementation (no longer XUL).
Can you please retest on trunk (TB65) ?

[toralf (toralf-foerster)]

I'd say, this is solved with current version 60.2.1