Intent to Deprecate and Remove: Activation of tabs with window.confirm()

瀏覽次數:173 次
跳到第一則未讀訊息

Avi Drissman

未讀,
2018年6月6日 下午1:00:492018/6/6
收件者:blink-dev
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.

If we look at things back on 1 Jan 2018, before activation was removed from window.alert(), we see several things. As an example of an abused feature, we can look at how the alert dialog was closed. It was closed in quite a few ways, with a button-click dismissal hanging around 65%. However, at the same time, we see that the confirm dialog was dismissed nearly 100% of the time with a button-click. In addition, we see that the confirm dialog was shown from the foremost tab nearly 100% of the time. This shows that at the time, while the alert dialog had quite a bit of abuse, the confirm dialog had very little abuse.

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.
Firefox: Shipped. Firefox does not activate tabs with window.confirm() as of Firefox 44. https://bugzilla.mozilla.org/show_bug.cgi?id=332195
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

Jochen Eisinger

未讀,
2018年6月6日 下午1:04:422018/6/6
收件者:Avi Drissman、blink-dev
lgtm1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAZUqaFiw4SYZ0iY%2BUJgw9SXbtkBqm7wW2RcwyxFHYj3Nw%40mail.gmail.com.

Anne van Kesteren

未讀,
2018年6月6日 下午1:08:322018/6/6
收件者:Avi Drissman、blink-dev
On Wed, Jun 6, 2018 at 7:00 PM, Avi Drissman <a...@chromium.org> wrote:
> 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.
>
> ...
>
> This makes us conform with all other major browsers.

This claim seems inaccurate. E.g., Firefox does not return
immediately. It shows the dialog, but does not focus the tab.


--
https://annevankesteren.nl/

Avi Drissman

未讀,
2018年6月6日 下午1:16:582018/6/6
收件者:Anne van Kesteren、blink-dev
You are correct. It matches Firefox in not activating the tab. It does not match Firefox in the behavior of immediate return. Apologies for the conflation of what I want to achieve and how I want to achieve it.

For achieving no activation, we're boxed in a bit. We can't have a tab with a suspended JavaScript world in the background, as there are plenty of reasons why it could share a render process, and tabs that share the render process could be in the foreground and not be responsive to the user. Changing behavior depending on whether the render process was shared would make things unpredictable. As noted in the original design doc, immediately returning is the approach we'll be taking, and the metrics show that it should have little effect on legitimate use cases.

Avi

Anne van Kesteren

未讀,
2018年6月6日 下午1:38:442018/6/6
收件者:Avi Drissman、blink-dev
On Wed, Jun 6, 2018 at 7:16 PM, Avi Drissman <a...@chromium.org> wrote:
> For achieving no activation, we're boxed in a bit. We can't have a tab with
> a suspended JavaScript world in the background, as there are plenty of
> reasons why it could share a render process, and tabs that share the render
> process could be in the foreground and not be responsive to the user.

That's true for Firefox too, but granted, nested event loops aren't
great. Since you've been successful thus far it might be worth
standardizing this behavior and getting other browsers to adopt it.
Basically making these methods depend on the "visibility" concept.


--
https://annevankesteren.nl/

David Benjamin

未讀,
2018年6月6日 下午1:49:092018/6/6
收件者:Anne van Kesteren、Avi Drissman、blink-dev
Nested event loops are a nightmare of reentrancy and weird behavior. One of my "fondest" debugging memories in Chrome is a crash involving five event loops across over two processes, back when we still did NPAPI. :-)

They also don't quite work right in many web-exposed ways. For instance, you can only dismiss the dialogs in LIFO order. I believe Firefox hides them immediately, but doesn't return to JavaScript until later, when the relevant event loop is one top.

So I think it's very strongly preferable to avoid the nested event loop here.

David

Rick Byers

未讀,
2018年6月6日 下午2:42:232018/6/6
收件者:David Benjamin、Anne van Kesteren、Avi Drissman、blink-dev
Wow, that data is quite compelling Avi, thank you!  The correspondence between the rise of confirm in the background and dismissing confirm dialogs via tab switching is even more clear if you do 1-day aggregation and overlay them on the same graph (attached).  To me, the most likely conclusion from the numbers is that >95% of all confirm dialogs shown while a tab are hidden are abusive (and likely >>95%). That suggests to me that action is urgent.  

I think there's some risk of legitimate site breakage (the UseCounter before all this was still quite high around 0.15%), but I suspect the severity of breakage will be low.  Specifically we can see from your data that we can already predict with high confidence that when a confirm dialog is shown while a tab is in the background, it will be dismissed by the user by switching tabs.  So since that's already what's happening in the overwhelming majority of cases, your proposed change is simply automating that for the user.

I like Anne's suggestion of trying to standardize the dialog behavior based on visibility.  But given that the spec already allows UAs to return false at their discretion, and there's active abuse, I don't think we should block this intent on that.  Avi, can you file a bug on the HTML spec please to suggest adding specific language requiring confirm, alert and prompt to all return immediately when the Document is hidden?  I can imagine other implementers will want to wait to confirm your change survives a hitting Chrome stable without causing problems.  But after that, hopefully changing the spec and adding some web-platform-tests will be non-controversial.

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
Screenshot from 2018-06-06 14-35-55.png

Avi Drissman

未讀,
2018年6月6日 下午3:12:362018/6/6
收件者:Rick Byers、David Benjamin、Anne van Kesteren、blink-dev
Rick, thank you for your support. I have two notes on your spec suggestion.

First, because window.alert() doesn't have to block, Chrome does not ignore window.alert() calls in hidden tabs, and I have no current plans to change that. Granted, window.alert() calls are wildly misused/abused too (see their dismissal rates nowadays, where 80% of the time alert dialogs are dismissed because the page fired a second, subsequent alert without waiting for a reply from the first), but I wanted to point out that you're requesting me to go further in the spec than I had requested. (I don't object, though 😇.)

Second, with regard to the window.confirm() and window.prompt calls, technically speaking, I'm asking to ignore calls when the page is not "foremost", which is not quite equivalent to "hidden" as defined by the spec. There is only one "foremost" page, the active tab in the front window, while active tabs in non-front windows wouldn't be "hidden".

I'm OK with asking for the spec change; know though that what I'm proposing doesn't quite match what you propose.

Avi

Rick Byers

未讀,
2018年6月6日 下午3:26:082018/6/6
收件者:Avi Drissman、David Benjamin、Anne van Kesteren、blink-dev
Thanks for the clarification Avi.  I'm sorry, I didn't mean to actually have a design debate here.  I just wanted to suggest that we follow up with the HTML spec community and see what we can do to get more alignment between browsers on the details here over time.

Thank you!
  Rick

Avi Drissman

未讀,
2018年6月6日 下午3:48:012018/6/6
收件者:Rick Byers、David Benjamin、Anne van Kesteren、blink-dev
No disagreement from me. Thank you.

Yoav Weiss

未讀,
2018年6月6日 下午4:57:302018/6/6
收件者:Avi Drissman、Rick Byers、David Benjamin、Anne van Kesteren、blink-dev
LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACWgwAYzwchO6vbCcwMHV5yozDxo9dcSohodXFhEuv-N%3DmOopg%40mail.gmail.com.

Daniel Bratell

未讀,
2018年6月7日 上午10:51:382018/6/7
收件者:Avi Drissman、Yoav Weiss、Rick Byers、David Benjamin、Anne van Kesteren、blink-dev
(LGTM4 - yes, not needed, but I found it such a compelling and well analyzed presentation of the problem and solution that I wanted to add a bonus lgtm)

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEggRih-sHTQ7PMvMiDHG2vOAcHzTbY0Q7oE7NyXunBHUQ%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

Avi Drissman

未讀,
2018年6月8日 下午3:40:332018/6/8
收件者:Rick Byers、David Benjamin、Anne van Kesteren、blink-dev
I opened a bug on the HTML spec; we can discussion options there.

On Wed, Jun 6, 2018 at 2:42 PM Rick Byers <rby...@chromium.org> wrote:
回覆所有人
回覆作者
轉寄
0 則新訊息