Intent to Ship: window.prompt() will not activate parent page
Avi Drissman
Contact emails
Spec
The relevant spec here is https://html.spec.whatwg.org/#dom-prompt .
Summary
If a document in a background tab calls window.prompt(), currently that tab is brought to the front, and the user is presented with the prompt dialog. As part of phase 1 of Project OldSpice, this will no longer be the case; if a document in a background tab calls window.prompt() then the call to prompt() will return immediately, and no dialog will be shown to the user for that call to prompt(). If the tab is foremost (if it is the active tab in the front window), then the call will show a dialog. Specifically, this removes the ability to use window.prompt() to bring a tab to the front against the user’s will.
The ability for pages to bring themselves forward using the window alert API (alert/confirm/prompt) is user-hostile, as it interrupts what the user is doing in whatever tab they’re working in. It is also not required by the spec, which also gives us discretion to not show a dialog at all.
The usage metrics for window.prompt() is 0.0007%, which is well below the cutoff of 0.03% required for feature removal. This is not an intent to remove the feature, just to remove some power from it that isn’t required by the spec and that is user-hostile.
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Android and desktop behaviors when it comes to dialogs are already different. In the future, some OldSpice interventions will come to mobile, but right now this is desktop only.
Interoperability and Compatibility Risk
Neither Firefox nor Safari nor Edge allows this activation, though they differ in details.
Firefox doesn’t allow pages to pull themselves to the front (via dialogs) by default, although permission can be granted by the user. Firefox labels the tab as needing attention. Firefox does not suppress the dialog, but preserves it until the user switches to the tab. That is accomplished by nesting event loops, which is troublesome for them and therefore something we do not want to do.
Safari doesn’t allow pages to pull themselves to the front (via dialogs) and doesn’t provide it as an option. It provides no visible indication that a page has put up a dialog. Safari does not suppress the dialog, but preserves it until the user switches to the tab. However, this causes any tabs that share a renderer with the alerting tab to hang, beachballing the user with no indication of why that is happening. This is also something we do not want to do.
Edge doesn’t allow pages to pull themselves to the front (via dialogs) by default, and it labels the tab as needing attention. Edge does not suppress the dialog, but preserves it until the user switches to the tab. It is unknown what mechanism it uses.
Given the downsides to trying to preserve dialogs and the need for simplicity and consistency, we are opting to entirely suppress prompt() dialogs from background tabs rather than attempt to preserve them.
Entry on the feature dashboard
https://www.chromestatus.com/feature/5637107137642496
