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)

Product:
Toolkit
Component:
Content Prompts
Platform:
x86
macOS
Type:
defect

Tracking

()

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.
blocking2.0: --- → ?
Similar to bug 476541 ?
Perhaps, but this particular testcase doesn't use a sheet, and used to work without tab-modal alerts.
Works fine on Windows 7 in current nightly builds; looks like a Mac-specific bug.
blocking2.0: ? → betaN+
This sounds identical to 476541, duping.  Reopen if I'm wrong.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
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
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
The patch on bug 622326 seems to solve this for me.
Depends on: 622326
Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.
Component: General → Notifications and Alerts
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.)

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 → --
Component: Notifications and Alerts → Content Prompts

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.