Open
Bug 615931
Opened 14 years ago
Updated 7 months ago
Putting up tab-modal alert while print dialog is up causes 100% CPU hang
Categories
(Toolkit :: Content Prompts, defect)
Tracking
()
NEW
People
(Reporter: bzbarsky, Unassigned, NeedInfo)
References
Details
(Keywords: hang)
Testcase (not attaching so people don't click this by accident): data:text/html,<body onload="print();setTimeout(function() {alert('x');}, 0);"> If I load that, my browser starts using 100% of CPU and stops responding to input; C++ stack is in jaeger-land; JS stack is in openTabPrompt. I'm on Mac in case that matters.
Reporter | ||
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 1•14 years ago
|
||
Similar to bug 476541 ?
Reporter | ||
Comment 2•14 years ago
|
||
Perhaps, but this particular testcase doesn't use a sheet, and used to work without tab-modal alerts.
Comment 3•14 years ago
|
||
Works fine on Windows 7 in current nightly builds; looks like a Mac-specific bug.
Updated•14 years ago
|
blocking2.0: ? → betaN+
Comment 4•14 years ago
|
||
This sounds identical to 476541, duping. Reopen if I'm wrong.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Comment 5•14 years ago
|
||
Was just looking at this when you duped it! ;) Part of this is the same, part of it is different... If I flip prompts.tab_modal.enabled to use window-modal prompts, I get no CPU pegging but the browser is unusable exactly because of bug 476541. That will be a tough thing to fix in general; it's a classic example of nested event loops, where the print dialog can't respond to anything until the alert()'s event loop stops spinning. [Though it's particularly bad here, because the print dialog is window-modal, so you can't even interact with the alert()!] But when using a tab-modal prompt, I do see the CPU getting pegged. This seems to just be the expected processNextEvent loop (in nsPrompter::openTabPrompt), but why this is pegging the CPU is unclear. Just overhead due to spinning this loop from JS instead of natively (as is the case with a window-modal prompt)? Or are we spinning the loop more often (more events)? [Leaving the blocking2.0 flag cleared, since even if we fix the CPU problem you'd still have a wedged browser per bug 476541.]
Status: RESOLVED → REOPENED
blocking2.0: betaN+ → ---
Resolution: DUPLICATE → ---
Summary: Putting up tab-modal alert while print dialog is up hangs browser → Putting up tab-modal alert while print dialog is up causes 100% CPU hang
Comment 6•14 years ago
|
||
To clarify, I'm reopening this for the narrow issue of CPU usage, which is not an expected part of the bug 476541 issue. I'd like to understand that better.
Status: REOPENED → NEW
Comment 7•14 years ago
|
||
The patch on bug 622326 seems to solve this for me.
Comment 8•10 years ago
|
||
Bulk move to Toolkit::Notifications and Alerts Filter on notifications-and-alerts-component.
Component: General → Notifications and Alerts
Comment 9•9 years ago
|
||
This seems to work for me in the current Nightly (OS X 10.9.5) with e10s turned off and tab-modal alerts (the default): 1) the dialogs open on top of each other 2) you can dismiss them only in the right sequence (first the alert, then the print dialog) 3) CPU usage is ~10%. I don't know what's the bug for #2 is. (Bug 476541 seems to be about everything and nothing in particular.)
Comment 11•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: critical → --
Updated•10 months ago
|
Component: Notifications and Alerts → Content Prompts
Comment 12•7 months ago
|
||
The severity field is not set for this bug.
:mtigley, could you have a look please?
For more information, please visit BugBot documentation.
Flags: needinfo?(mtigley)
You need to log in
before you can comment on or make changes to this bug.
Description
•