727801 - tab modal prompts like alert() are blocked on prompts from other tabs

Status: UNCONFIRMED

(Toolkit :: Content Prompts, defect)

Description

[Jochen Eisinger]

To reproduce:

1) open the attached file in to separate tabs.
2) click on "run test" in the first tab
3) click on "run test" in the second tab
4) close the prompt in the first tab
5) close the prompt in the second tab

Notice that the alert() call in the first prompt does not return until you close the prompt in the second tab, i.e. the second tab is holding the first one hostage.

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

Reopen if you attach the test file, otherwise this bug is meaningless

Comment 3

[Jochen Eisinger]

Attachment: test case

The attachment was in 727802, no idea why bugzilla created two bugs... anyway, here it is again

Comment 4

[Nickolay_Ponomarev]

This is a well-known issue: we spin an event loop from alert() and other modal dialogs until the alert is dismissed. I couldn't find the bug where it's tracked though...

Comment 5

[Matthew N. [:MattN]]

Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.

Comment 6

[:Gijs (he/him)]

This now bites us in bug 1234937. We can potentially fix beforeunload because we control all the creators of the prompts, but fixing web content is either hard or impossible, AIUI. We'd need cooperation from the JS engine for the page's JS to be "blocked" while other JS still runs in the same process, without the processNextEvent loop we currently use. Dolske, do you have ideas about this and/or do you know people we could poke about this? The current state of affairs is pretty messy, and I'd like to be able to do something general instead of hacking around these things for beforeunload...

Comment 7

[Justin Dolske [:Dolske]]

AFAIK it's not possible to fix the general case without a complete overhaul of the JS engine and xpconnect.

At least, that's true for things like confirm() / alert(), because the API's results are directly observable by web content. But maybe it's possible to sidestep this with onbeforeunload? The page kinda-sorta doesn't directly observe the result of the prompt -- it just asks us to show a prompt (by returning a string from the event listener), and the page either closes or not.

If we implemented chrome support for async prompts (which would be useful for other things), we could show a prompt with spinning the event loop. Quite possible this would have some webcompat impact, but given that we've deliberately been clamping down on onbeforeunload (and some browsers don't even support it), maybe not a big deal.

OTOH, not much point in fixing rare onbeforeunload edge cases if we're going to just remove too.