Intent to Implement and Ship: Require user gesture for beforeunload dialogs

[Avi Drissman]

Contact email

a...@chromium.org

Summary

The beforeunload dialog will only be shown if the frame attempting to display it has received a user gesture or user interaction (or if any embedded frame has received such a gesture). (There will be no change to the dispatch of the beforeunload event, just a change to whether the dialog is shown.)

Motivation

The beforeunload dialog is an app-modal dialog, which makes it powerful, as it forces the user to drop whatever they're doing and respond to it. It is inherently user-hostile, as the user just gave a navigation request to the browser, but the browser turns around and questions the decision the user made.

On one hand, this can be used in a positive way, to warn a user if they are going to be losing data due to a navigation.

On the other hand, this can and is abused to annoy users into not leaving a page. While the ability for a page to provide text for the beforeunload dialog was removed a while ago, beforeunload dialogs remain a vector of abuse. In particular, beforeunload dialogs are an ingredient of scam websites, where autoplay audio and threatening text provide a context where the Chromium provided "are you sure you want to leave this page" message becomes worrisome.

We want to thread the needle, and only allow good uses of the beforeunload dialog. Good uses of the dialog are those where the user has state that might be lost. If the user never interacted with the page, then the user cannot have any state that might be lost, and therefore we do not risk user data loss by suppressing the dialog in that case.

Firefox shipped this in Firefox 44; we would be aligning with them.

Interoperability and Compatibility Risk

Edge: No signals

Firefox: Shipped in Firefox 44

Safari: No signals

Web developers: No signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/707007

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5082396709879808

Requesting approval to ship?

Yes

[owe...@google.com]

I don't have full context on this change, but naively this seems pretty good to me!

I'd also note that we have the Background Sync API and Beacon API for ensuring data makes it to the server before the tab is closed. Obviously most sites don't today, but finding ways to encourage devs to do that would really help us make progress along this path of solving the pain of beforeunload dialogs.

[Chris Dumez]

Comment inline.

On Thursday, March 30, 2017 at 2:08:12 PM UTC-7, Avi Drissman wrote:

Contact email

a...@chromium.org

Summary

The beforeunload dialog will only be shown if the frame attempting to display it has received a user gesture or user interaction (or if any embedded frame has received such a gesture). (There will be no change to the dispatch of the beforeunload event, just a change to whether the dialog is shown.)

Motivation

The beforeunload dialog is an app-modal dialog, which makes it powerful, as it forces the user to drop whatever they're doing and respond to it. It is inherently user-hostile, as the user just gave a navigation request to the browser, but the browser turns around and questions the decision the user made.

On one hand, this can be used in a positive way, to warn a user if they are going to be losing data due to a navigation.

On the other hand, this can and is abused to annoy users into not leaving a page. While the ability for a page to provide text for the beforeunload dialog was removed a while ago, beforeunload dialogs remain a vector of abuse. In particular, beforeunload dialogs are an ingredient of scam websites, where autoplay audio and threatening text provide a context where the Chromium provided "are you sure you want to leave this page" message becomes worrisome.

We want to thread the needle, and only allow good uses of the beforeunload dialog. Good uses of the dialog are those where the user has state that might be lost. If the user never interacted with the page, then the user cannot have any state that might be lost, and therefore we do not risk user data loss by suppressing the dialog in that case.

Firefox shipped this in Firefox 44; we would be aligning with them.

Interoperability and Compatibility Risk

Edge: No signals

Firefox: Shipped in Firefox 44

Safari: No signals

Signal: https://trac.webkit.org/changeset/214277/webkit

[Avi Drissman]

Thank you, Chris! I didn't realize that they'd done that.

So:

Edge: No signals

Firefox: Shipped in Firefox 44

Safari: Not yet shipped but landed in the repo

[Rick Byers]

I definitely think this is a good change to be making.  Just a couple details:

Note this should be a "deprecate and remove" since it's a breaking change.  +Joe to get it on the radar for the deprecations blog post.

From a quick look at the WebKit CL I'm guessing their behavior is more permissive.  Eg. if the user has interacted with a page, but not an iframe inside of it and that iframe attempts to pop a beforeunload dialog, does it get shown?  Avi, do you have a test case for this we can try on different browsers?

Do we have any UMA stats to tell us how often this will trigger?  If we were just matching Safari and Firefox I wouldn't worry about it, but if they're not doing the more sophisticated iframe thing, then I think our compat risk is much higher than theirs and ideally something we'd be able to put an upper-bound on.

[Avi Drissman]

On Sat, Apr 1, 2017 at 9:51 AM, Rick Byers <rby...@chromium.org> wrote:

Note this should be a "deprecate and remove" since it's a breaking change.  +Joe to get it on the radar for the deprecations blog post.

If you prefer to read this intent as

"Intent to Deprecate and Remove: beforeunload dialogs without user gesture"

I'm OK with that retitling and all that goes with it.

 

Avi, do you have a test case for this we can try on different browsers?

I have been using the w3schools page for testing, and they actually have their beforeunload handler in an iframe.

 

Do we have any UMA stats to tell us how often this will trigger?  If we were just matching Safari and Firefox I wouldn't worry about it

I don't have stats for this.

The reason I proposed doing this at the frame level was to parallel what's planned for the Vibration API. If it makes more sense to do this at the page level, matching Safari and Firefox (which might be desirable for web platform consistency), I would be happy to propose doing that. It would be technically trivial.

If this Intent were officially an Intent to Deprecate and Remove, and it were modified so that a gesture anywhere on the page would qualify any frame to show the beforeunload dialog (matching Firefox and Safari), would I have your LG?

Avi

[Joe Medley]

"+Joe to get it on the radar for the deprecations blog post."

Got it. Thanks.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Rick Byers]

On Sat, Apr 1, 2017 at 5:31 PM, Avi Drissman <a...@chromium.org> wrote:

On Sat, Apr 1, 2017 at 9:51 AM, Rick Byers <rby...@chromium.org> wrote:

Note this should be a "deprecate and remove" since it's a breaking change.  +Joe to get it on the radar for the deprecations blog post.

If you prefer to read this intent as

"Intent to Deprecate and Remove: beforeunload dialogs without user gesture"

I'm OK with that retitling and all that goes with it.

Don't worry about forking the thread or anything - mainly we just need to ensure it's on web dev's radar as a breaking change, not just a new feature.

Avi, do you have a test case for this we can try on different browsers?

I have been using the w3schools page for testing, and they actually have their beforeunload handler in an iframe.

 

Do we have any UMA stats to tell us how often this will trigger?  If we were just matching Safari and Firefox I wouldn't worry about it

I don't have stats for this.

The reason I proposed doing this at the frame level was to parallel what's planned for the Vibration API. If it makes more sense to do this at the page level, matching Safari and Firefox (which might be desirable for web platform consistency), I would be happy to propose doing that. It would be technically trivial.

So that's definitely what Safari and Firefox are doing - looking only at the page level, right?  I briefly tried the latest WebKit nightly build on the W3CSchools page and that appeared to be the behavior to me.

If this Intent were officially an Intent to Deprecate and Remove, and it were modified so that a gesture anywhere on the page would qualify any frame to show the beforeunload dialog (matching Firefox and Safari), would I have your LG?

Yes, my understanding is that would be extremely low risk, I'd have no problem doing that without any compat analysis.

But I think it's also lower benefit.  Do we have evidence of beforeunload abuse from iframes?

We could always split this work into two parts - do the simple thing matching Safari/Firefox now while also adding metrics to see how often iframes are popping unload dialogs without the frame itself having seen a user gesture?  WDYT?

Avi

[Avi Drissman]

On Mon, Apr 3, 2017 at 10:46 AM, Rick Byers <rby...@chromium.org> wrote:

So that's definitely what Safari and Firefox are doing - looking only at the page level, right?  I briefly tried the latest WebKit nightly build on the W3CSchools page and that appeared to be the behavior to me.

It's clear from the WebKit change in trac that doing this at the page level is what WebKit is doing.

I believe I was wrong about Firefox; Firefox appears to be as restrictive as I was proposing we be.

First, look at the diffs on the implementation bug for Firefox. The "has interacted" bit lives on nsIDocument which is per-frame, because when there is a user interaction, the EventStateManager walks up the document tree and updates all of them to have the bit set. The beforeunload dialog handling lives in nsDocumentViewer, and appears to be per-frame if I'm reading the change correctly.

Second, play with that sample page on w3schools. If you click on the frame with the beforeunload handler you get the dialog, but if you click everywhere on that page but that frame, you get no dialog.

Assuming that's correct (Mozilla folks, can you confirm?), that's as strict as I was proposing, and there's less worry about web compat as Mozilla has been shipping this for a year. Given that that's what out there, I'd like to target our behavior as matching Firefox, and now propose what I was originally proposing, to do it at the frame level.

We could always split this work into two parts - do the simple thing matching Safari/Firefox now while also adding metrics to see how often iframes are popping unload dialogs without the frame itself having seen a user gesture?  WDYT?

First, the delta between doing it at the page vs frame level in terms of user benefit is low enough that I would probably move to more promising interventions and return later.

But given my findings that Firefox is shipping today (and has shipped for a year) this intervention at the frame level, I would very much like to match them with that, to minimize the confusion to web authors and maximize cross-browser consistency.

Avi

[Nasko Oskov]

This will also not increase the state we need to replicate across processes when we have out-of-process iframes on a page. We have been moving more and more to a world where we make state be frame/document bound instead of page bound, so I'd prefer we keep it that way, especially since Firefox has already been shipping that for a while.

[Avi Drissman]

To be clear:

Intent to Deprecate and Remove: beforeunload dialogs without user gesture

This will be done at the frame level (the frame or a child frame requires a user gesture before it's allowed to show a beforeunload dialog). This matches what Firefox has been shipping since 44, so it raises few compatibility issues.

WebKit is going in this direction too, though their current implementation is a bit weaker. I would like to converge on per-frame but that's a different discussion.

Can I get thoughts from API OWNERs?

Thank you.

[Rick Byers]

Thanks Avi.

I played with Firefox a bit and I agree that appears to be their behavior. /cc Gijs who made the change in Gecko (see the whole thread here).  I agree the compat risk should be low enough that we should just try to ship this (in particular, the severity of breakage is likely low and benefit to user annoyance is high).  LGTM1

BTW I don't think you mentioned earlier that the spec, while somewhat vague, has some guidance on this:

"The user agent is encouraged to avoid asking the user for confirmation if it judges that doing so would be annoying, deceptive, or pointless. A simple heuristic might be that if the user has not interacted with the document, the user agent would not ask for confirmation before unloading it."

Rick

[Dimitri Glazkov]

LGTM2

[Chris Harrelson]

LGTM3

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Avi Drissman]

Thank you!

I'm going to be OOO for most of next week, when M59 branches, so I'll aim for M60.

[Chris Bentzel]

Forking thread to not confuse with the intent.

I'm very excited to see this change in behavior. Have there been considerations for a longer term removal of beforeunload handlers?

With background sync and the recent fetch keep-alive proposal (on blink-network-dev) it feels like we will have primitives that can address out-of-band data syncs. Robust services will have to deal with killed tabs as well due to browser crashes, OOM killing, power-cycles, etc.

[PhistucK]

I do not think this event should go away. It is very useful for critical alerts (I understand it is being abused, but site engagement and user gestures can mitigate the vast majority of abuse mechanisms).

For example, you plan to send an urgent e-mail/form, you write/fill it and get distracted and close the tab because you think you sent it. While you do not lose the text itself, others will not get the information in time which may cause a huge unnecessary loss.

How would you resolve such a situation without this event?

The difference between unexpected external failures (crash, our of memory...) and explicit user actions (closing a window, closing a tab) is that in the former case, it would probably be pretty clear to the user that the action they were about to perform was not accomplished, while in the latter case, it might be much less clear.

☆PhistucK

--

[Avi Drissman]

But the beforeunload event is already unreliable on mobile.

My personal opinion is that people should migrate off of beforeunload and unload events and those events should eventually be removed from the platform, but I don't see that happening any time soon, and I have lower-hanging dialog fruit to go after first.

Avi

[PhistucK]

That does not answer my question, you simply say that it is harder on mobile. But how would you accommodate scenarios of this type in a web browser?

Native applications can do so and you seem to think it is fine to take it away (or to keep it unreliable on mobile). But the web should not be inferior.

☆PhistucK

[Gijs Kruitbosch]

FWIW, I'm happy Blink is considering this change, so +1 from me, even though that really doesn't count for much. :-)

Yes, the bit is per-frame. I think when this shipped there was 1 bug filed by someone who didn't like the change ( https://bugzilla.mozilla.org/show_bug.cgi?id=1234942 ), but that was all the feedback I heard... Note also that we do still fire the event, we just end up not showing a dialog. Finally note that there's a vaguely interesting 'gotcha' here regarding modifier keys for shortcuts etc. So if web content is focused and as a user, I press accel-w to close a tab/window/whatever, does the accel (or w) keydown trigger the flag ( https://bugzilla.mozilla.org/show_bug.cgi?id=1345830 ).

On 07/04/2017 22:36, PhistucK wrote:

For example, you plan to send an urgent e-mail/form, you write/fill it and get distracted and close the tab because you think you sent it. While you do not lose the text itself, others will not get the information in time which may cause a huge unnecessary loss.

How would you resolve such a situation without this event?

You use a service worker to send a push notification (or an in-app thing in a remaining open tab) based on the unload event (or when some system notices no editing windows are open for a draft).

The event is broken in many ways, including:
- mandated (tab-/app-)modal UI
- because of this, focus stealing
- synchronous and required, which is bad because
-- web authors do dumb things like synchronous cross-internet XHRs in them so then the content process hangs while the user tries to navigate / close a content window
-- Firefox (and I guess Chrome, though I'm not familiar with their implementation and I'd be interested if Avi has further details on this!) needs to go talk to the website content process in some way when closing a tab to check if they can really close that tab, if it has a beforeunload handler; this kind of communication either makes UI interactions seem slow (if the content process is busy in that or another tab), or require weird mechanics where you proactively go close/hide the tab, but then might need to bring it back once you hear back from the other process that the website didn't want the user to close it.
- per-frame. So now you need mechanics to avoid prompting the user 15 times for websites that abuse it
- can be triggered by web content navigating the window, further causing annoyance/abuse in some situations

The difference between unexpected external failures (crash, our of memory...) and explicit user actions (closing a window, closing a tab) is that in the former case, it would probably be pretty clear to the user that the action they were about to perform was not accomplished, while in the latter case, it might be much less clear.

I don't think this is the case. What's the difference between closing my browser having forgotten about that background tab that was open, or something crashing my browser (or the relevant content process) with me having forgotten about that background tab that was open? I don't think there's any difference at all.

~ Gijs

[PhistucK]

The difference is the lack of ability. In system failure/crash cases, you simply do not have the ability. In explicit cases, you do (as a browser). Native versus web should not mean less abilities to help the user not to make mistakes.

☆PhistucK

[Avi Drissman]

On Fri, Apr 7, 2017 at 5:58 PM, Gijs Kruitbosch <gijskru...@gmail.com> wrote:

FWIW, I'm happy Blink is considering this change, so +1 from me, even though that really doesn't count for much. :-)

I'll take it though :)

 

Finally note that there's a vaguely interesting 'gotcha' here regarding modifier keys for shortcuts etc. So if web content is focused and as a user, I press accel-w to close a tab/window/whatever, does the accel (or w) keydown trigger the flag ( https://bugzilla.mozilla.org/show_bug.cgi?id=1345830 ).

That possibility was also pointed out to me by Chris Dumez who is working on this for WebKit. In my preliminary tests, those command keys didn't trigger a user gesture. I wonder if the keyboard focus was in the tab at that point, though, but I'm not sure how to get the keyboard focus into the tab to really test the keyboard command without that being something that generates the user gesture.

Avi

[Avi Drissman]

Further comments.

On Fri, Apr 7, 2017 at 5:58 PM, Gijs Kruitbosch <gijskru...@gmail.com> wrote:

-- Firefox (and I guess Chrome, though I'm not familiar with their implementation and I'd be interested if Avi has further details on this!) needs to go talk to the website content process in some way when closing a tab to check if they can really close that tab

We track in the browser process whether or not the render processes have pages that have closing event handlers (i.e. beforeunload, unload). Things go much nicer if they don't (we can nuke render processes, etc) but yep, all the downsides.

if it has a beforeunload handler; this kind of communication either makes UI interactions seem slow

Well, not super-slow. There is a one-second timeout. If the browser asks the renderer to fire the beforeunload event, and it doesn't either get a request to show an "are you sure" dialog or an ACK that the event was processed within that timer, navigation proceeds.

weird mechanics where you proactively go close/hide the tab, but then might need to bring it back once you hear back from the other process that the website didn't want the user to close it.

Yeah, that would be weird. We haven't gone down that route.

 

- per-frame. So now you need mechanics to avoid prompting the user 15 times for websites that abuse it

We have code to handle this, though I'm not 100% sure it handles all edge cases. (The "stop bugging me" checkbox in the beforeunload dialog works for those situations, though.)

 

- can be triggered by web content navigating the window, further causing annoyance/abuse in some situations

I literally have a list of things I want to kill about dialogs, and this is already on that list.

Avi

[Gijs Kruitbosch]

On 07/04/2017 23:27, Avi Drissman wrote:

Further comments.

On Fri, Apr 7, 2017 at 5:58 PM, Gijs Kruitbosch <gijskru...@gmail.com> wrote:

-- Firefox (and I guess Chrome, though I'm not familiar with their implementation and I'd be interested if Avi has further details on this!) needs to go talk to the website content process in some way when closing a tab to check if they can really close that tab

We track in the browser process whether or not the render processes have pages that have closing event handlers (i.e. beforeunload, unload). Things go much nicer if they don't (we can nuke render processes, etc) but yep, all the downsides.

Yep yep, we have bugs on file to do the same, but as you note, only helps for tabs that don't [have the handlers].

if it has a beforeunload handler; this kind of communication either makes UI interactions seem slow

Well, not super-slow. There is a one-second timeout. If the browser asks the renderer to fire the beforeunload event, and it doesn't either get a request to show an "are you sure" dialog or an ACK that the event was processed within that timer, navigation proceeds.

Ah, our timeout is longer (5s, IIRC, though maybe we already shortened it to 2s after feedback - don't remember if that change made it from suggestion to patch to shipping). I guess we can shorten it (further), then. That sounds like beforeunload would also already be unreliable on desktop anyway? I don't mind, but... some people might. Is there (or should there be) spec provision for this?

- per-frame. So now you need mechanics to avoid prompting the user 15 times for websites that abuse it

We have code to handle this, though I'm not 100% sure it handles all edge cases. (The "stop bugging me" checkbox in the beforeunload dialog works for those situations, though.)

Right, as do we, with the same caveat. I guess what I'm saying is, it's all added complexity, same for keeping track in the parent whether a particular content process / renderer has those handlers. For questionable benefits. Anyway, I sense I'm preaching to the converted. :-)

- can be triggered by web content navigating the window, further causing annoyance/abuse in some situations

I literally have a list of things I want to kill about dialogs, and this is already on that list.

I don't seem to have access to that document (though I've heard the 'project oldspice' moniker before, so might have seen a different version). We have a list/tree of public bugs... Pretty sure we'd be happy to move forward / align in that domain, though I don't make resourcing decisions.

~ Gijs

[Gijs Kruitbosch]

Gah, it's late, one more comment:

On 07/04/2017 23:05, Avi Drissman wrote:

 

Finally note that there's a vaguely interesting 'gotcha' here regarding modifier keys for shortcuts etc. So if web content is focused and as a user, I press accel-w to close a tab/window/whatever, does the accel (or w) keydown trigger the flag ( https://bugzilla.mozilla.org/show_bug.cgi?id=1345830 ).

That possibility was also pointed out to me by Chris Dumez who is working on this for WebKit. In my preliminary tests, those command keys didn't trigger a user gesture. I wonder if the keyboard focus was in the tab at that point, though, but I'm not sure how to get the keyboard focus into the tab to really test the keyboard command without that being something that generates the user gesture.

From a super-naive check, looks like Blink supports HTML5 <input autofocus>, which should do the trick?

I think generally Firefox (re-)focuses web content after some navigations, which might make the problem worse for Firefox than for Chrome if Chrome doesn't ever do that.

Also, if you tab from one document (or browser UI) into a(nother) content document, where does the tab key that moves focus fire its keyup/keydown event? I would assume at least the keydown fires only in the doc where focus was to start with, not where focus ends up, but I am actually not a Gecko hacker or a spec expert, so I could be wrong. But that would mean focus would then be somewhere that still hadn't seen "proper" key events, so might not be flagged as 'user has interacted with this document'. Depends on the implementation, I suppose, and if just a (user-triggered) focus event would count.

~ Gijs

[Avi Drissman]

Ah.

That list is kind of a todo/wish list:

• autodismissing dialogs + suppress background prompt (rolling out now)
• maybe gate dialogs on site engagement?
• suppress beforeunload dialogs without user gesture (this!)
• suppress background alert()
• suppress background confirm()
• suppress beforeunload dialogs from non-user-initiated navigations

The first item on that list is what I call "Project OldSpice". That doc is public.

"resourcing decisions" This is kind of a 20% project for me; I finally just got angry enough to do something about dialogs.

We and Chris should totally align via the standards process.

Avi

[Avi Drissman]

<input autofocus>...

Yep, that does it. :(

[Rick Byers]

On Fri, Apr 7, 2017 at 5:58 PM, Gijs Kruitbosch <gijskru...@gmail.com> wrote:

FWIW, I'm happy Blink is considering this change, so +1 from me, even though that really doesn't count for much. :-)

It totally does, thank you!  Getting feedback on our plans from implementors in other engines is one of the primary goals of our web platform change process, and one of the main signals the API owners look at when making decisions :-).

[danielher...@gmail.com]

This would break my extension. I use beforeunload in a pinned tab to provide confirmation when closing multiple tabs. Can extension pages and content scripts be excluded from this change?