If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Putting up tab-modal alert while print dialog is up causes 100% CPU hang

NEW
Unassigned

Status

()

Toolkit
Notifications and Alerts
--
critical
7 years ago
2 years ago

People

(Reporter: bz, Unassigned)

Tracking

({hang})

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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: --- → ?

Comment 1

7 years ago
Similar to bug 476541 ?
Perhaps, but this particular testcase doesn't use a sheet, and used to work without tab-modal alerts.

Comment 3

7 years ago
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
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 476541
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

Comment 7

7 years ago
The patch on bug 622326 seems to solve this for me.

Updated

7 years ago
Depends on: 622326
Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.
Component: General → Notifications and Alerts

Comment 9

2 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.)
Duplicate of this bug: 791671
You need to log in before you can comment on or make changes to this bug.