Primary eng emails
Summary
Today, when a page calls window.confirm(), its window is activated and its tab is brought to the front when the dialog is shown.
What I am requesting is to remove the activation. If a document in a background tab were to call window.confirm() then the call to confirm() would return immediately (returning false), and no dialog would be shown to the user for that call to confirm(). If the tab were to be foremost (if it was the active tab in the front window), then the call would show a dialog.
Motivation
Performing activation with window.alert() had been abused by sites for years, allowing sites to force themselves to the front, disrupting whatever the user was doing. (This is user-hostile behavior.)
Activation was removed from window.prompt() in May 2017. Activation was removed from window.alert() in Chrome 64. The only remaining dialog that can activate its caller's webpage is window.confirm().
The abuse has started to move to window.confirm().
(All the following metrics are 90-day metrics with 28-day aggregation. If you work at Google and want to investigate these metrics on your own, please feel free to contact me for the details.)
The difficulty in working with metrics for things like the JavaScript dialogs is that dialogs are very flexible. Therefore, the main metric we use as a proxy for abuse is how the dialog is closed. If the dialog is dismissed by the user clicking on one of its buttons ("OK"/"Cancel"), then we consider it a non-abusive dialog, and it if it is dismissed any other way, we consider it an abusive dialog. Those, of course, are super rough indicators, but they will do.
Activation was removed from the alert dialog in Chrome 64. However, it seems to have taken abusive sites until April to realize that the confirm dialog can still activate. If we look at metrics from 1 June 2018, we see that starting in the middle of April, the button-click dismissal rate of the confirm dialog has
plummeted from nearly 100% to 60%. In addition, we see that the confirm dialog has started to be shown from the non-foremost tab from
exactly the same point. I encourage you to switch between those two previous graphs. The correspondence between non-button-click dismissals and window.confirm() being called from a background tab is very close.
In case you think that something happened in the middle of April to cause user behavior to change, I give you a graph of the
absolute number of confirm dialogs shown. It's clear that these are
new confirm dialogs being shown from the background tabs that are eliciting a different (non-button-click dismissal) behavior from our users. Compare the shape of the growth on this graph to the shape of the previous two graphs. This is not a change in user behavior.
My conclusion is that in the middle of April some abuse library was updated and is creating abusive confirm dialogs, and that the legitimate uses of window.confirm will not be affected by restricting window.confirm() to a foremost tab (the active tab in the front window). We should therefore restrict it in that way.
Interoperability and Compatibility Risk
Edge: Shipped. Edge does not activate tabs with window.confirm() in Edge 38.14393.2068.0. I don't know when they removed it.
Safari: Shipped. Safari does not activate tabs with window.confirm() as of Safari 9.1.
This makes us conform with all other major browsers.
Alternative implementation suggestion for web developers
There is no replacement for the activation. For posing a question to the user and getting an OK/Cancel answer, there are dozens of alternative web technologies to choose from, ranging from the
<dialog> element to the
<form> element.
Usage information from UseCounter
Metrics are in the Motivations section.
Bug
Entry on the feature dashboard
Requesting approval to remove too?
Yes