671527 - alert() from inside gMsgCompose state listener sucks CPU

Status: RESOLVED DUPLICATE of bug 562977

(Core :: DOM: Core & HTML, defect)

Description

[Jonathan Kamens]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.124 Safari/534.30

Steps to reproduce:

Note: I'm filing this in Thunderbird instead of Core because I was unable to reproduce the issue from a simple JavaScript fragment in an HTML page in Firefox, so at least the particular manifestation of the issue that I'm describing appears to be Thunderbird-specific.

I was using alert() in the NotifyComposeBodyReady callback of a listener added with gMsgCompose.RegisterStateListener.

I know I'm supposed to use nsIPromptService, and indeed I've fixed my code to use it, but I don't think using bare alert() should have the following behavior.



Actual results:

As soon as the window created with alert() popped up, Thunderbird start sucking as much CPU as it could get, and didn't stop until I clicked the button to pop down the window.


Expected results:

Thunderbird shouldn't suck CPU when an alert() window is popped up.

nsIPromptService.alert() does not appear to have this problem.

Comment 1

[Wayne Mery (:wsmwk)]

Jonathan, can you trace it?

Comment 2

[Jonathan Kamens]

Attachment: zip with strace and lsof output

Sorry for the delay in responding.

Strace log of a few seconds of spinning, along with strace summary and lsof output, attached.

BTW, I'm now (in current trunk) seeing this in nsIPromptService.alert() as well.

Comment 3

[David :Bienvenu]

This is almost certainly a core issue, not a mail composition issue. You may be able to work around it by doing whatever it is you want to do using a timeout;

Comment 4

[Jonathan Kamens]

I checked the total CPU time of Thunderbird during a 60-second idle period: less than 1 CPU second was consumed.

Then I checked the total CPU time of Thunderbird during a 60-second period during which an alert() window was popped up: 12 CPU seconds.

It's no longer consuming 100% of a CPU, so that's better, but it seems to me that it's still consuming more CPU than can be justified for doing nothing but waiting for someone to click OK on an alert() pop-up.

I did notice that the progress bar at the bottom of the Thunderbird window was Cylon-ing for the entire 60 seconds and went away as soon as the alert() window was dismissed, so if I had to guess, I'd guess that the animation of the progress bar is what's sucking CPU. Consuming almost 25% of a fast CPU just to display a Cylon-ing progress bar seems like a bad idea in general. It suggests that any time anything CPU-bound is being done by the app that displays a progress bar, it's going to take 20% longer than it needs to because of the progress bar animation.

Comment 5

[Wayne Mery (:wsmwk)]

If progress bar is the only remaining issue, then can this report be closed?
I think we have a bug report about progress bar + compose (but please check).