Don't allow modal dialogs for background pages

[anirudhcmohan]

Remove the power from JavaScript dialogs by making them not block tab switching.

[jyasskin]

@martinthomson suggests making the dialogs tab-modal rather than making them only work in focused tabs.

[martinthomson]

Note that this isn't easy, it might also be extremely difficult. window.alert() and friends are synchronous and block script execution. Freeing the "main thread" for use by other windows - which can also synchronously call into the same window in some circumstances - isn't trivial.

[bzbarsky]

To be clear, Firefox implements such a thing. We do it by violating run-to-completion in some cases, effectively.

[martinthomson]

Violating run-to-completion seems like a reasonable compromise. These are crappy APIs.

[ojanvafai]

Last I saw, you could get Firefox into deadlock through judicious use of alerts. Maybe those were just bugs that have been fixed though. I agree that violating run-to-completion is fine in principle in this case, but I think we can get away with something simpler.

The specific thing we're working on is queuing up alerts done in background tabs but continuing JS execution as if the user had clicked OK on the alert. For confirm and prompt we're hoping to just not fire them as we think it's probably extremely rare to use confirm/prompt in background tabs.

[avidrissman]

I am confused by the title and first comment to this bug. I see "Don't allow modal dialogs for background pages" and "Remove the power from JavaScript dialogs by making them not block tab switching" as two very different things.

Chromium already implements the latter, not allowing dialogs to block tab switching, by auto-dismissing them when the user switches tabs.

As for the former, changing alert/confirm/prompt dialog behavior in the background is half done.

To add precision to @ojanvafai's answer: For alert, our plan is if the tab is foremost (front tab in front window) we will pause the JS engine until the user clicks "OK", but if the user switches to a different tab, or if the page shows the dialog while not foremost, we will return from the alert call and show the dialog when the page comes to the front again. We are not planning on queueing dialogs (this was old info). Dialogs are one-per-page and if a page shows a new dialog we dismiss the old one. This work is being tracked as https://www.chromestatus.com/feature/6477774290157568, and is underway in https://crrev.com/c/720176.

Chromium already ignores prompt in background tabs. This was tracked as https://www.chromestatus.com/feature/5637107137642496. The plan is to ignore confirm in background tabs as well.

While the title is "don't allow modal dialogs for background pages", the real motivation here is to remove activation of pages. Page activation enables problems ranging from popunders to URL spoofs. While Chromium can remove activation for alert while not completely disallowing it for background pages, confirm and prompt will not be able to be saved for use in background pages.

I am coming to this from the front end, so I'm not sure of the consequences of violating run-to-completion, and I certainly don't know enough to implement it. I believe my approaches to our dialog woes are spec compliant, user-friendly, and aren't that drastic.

[bzbarsky]

Just so we're clear, the goal of the Firefox behavior has little to do with dialogs from background tabs per se. The key part of the Firefox behavior is that a user should be able to completely ignore a dialog from any tab if they want to. If the foreground tab prompt()s you for something, and you want to go look the something up on the web, in Firefox you can, because these dialogs don't block the browser UI or other tabs.

It sounds like Chrome is trying to solve a quite different problem.

[avidrissman]

The key part of the Firefox behavior is that a user should be able to completely ignore a dialog from any tab if they want to.

That's exactly the problem we're trying to solve, too. We've already removed the app-modality from the dialogs, and we're removing the activation too.

[bzbarsky]

In my scenario above, in Chrome dev, the prompt will get dismissed if the user switches to a different tab to look something up.

You're trying to solve the "modal dialogs should not trap the user" problem, as far as I can tell, which is not the same as the problem Firefox was trying to solve with its design. (Which says nothing about which of those problems needs solving, from a user point of view.)

[domenic]

We're revisiting the interventions repo in an attempt to move everything to the appropriate issue trackers (in this case the one for the HTML Standard). See https://github.com/WICG/interventions/pull/72.

From what I can tell, the various participants here are discussing several possible behaviors:

• Making modals tab-modal instead of browser-modal. This probably requires violating run to completion.
• Making modals "event loop modal", i.e. they will block all the tabs that share an event loop (most notable in the case of opener relationships). This does not require violating run to completion.
• Auto-dismissing modals when switching tabs.
• Queuing up modals in background tabs, by returning to JS right away (and not blocking further script execution) but still showing the result to the user.

The current spec for modals is somewhat-intentionally vague and is trying to allow all sorts of things here. It allows early returns for any reason, and the pause spec says that implementations are encouraged to experiment with things that are not pausing. That said, by the exact letter of the spec I don't think violating run to completion is allowed, or auto-dismissing modals when switching tabs, or queuing up modals in background tabs (in particular there's nothing that says you can show a non-blocking alert after the user switches back).

In my opinion this isn't a big deal, as such "spec violations" aren't really web-observable (with the possible exception of RTC violations). And they seem unlikely to cause any significant interop issues where users get a broken experience in only one browser. But if anyone feels like we should flesh out the spec more in this area, or that the lack of interop around ways people are making modals less-terrible is causing issues in the wild, please raise an issue on whatwg/html and we'll definitely look into it.