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 (https://bugzilla.mozilla.org/show_bug.cgi?id=636905)
Safari: No signals
Web developers: Negative (initially shown with Firefox's implementation)

Ongoing technical constraints
None.

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

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 (https://bugzilla.mozilla.org/show_bug.cgi?id=636905)
Safari: In development (https://trac.webkit.org/changeset/214277/webkit)
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.
 

Summary
The beforeunload dialog will only be shown if the page attempting to display it has received a user gesture or user interaction. (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 (https://bugzilla.mozilla.org/show_bug.cgi?id=636905)
Safari: In development (https://trac.webkit.org/changeset/214277/webkit)
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.
 

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.

The spec has guidance in this area (https://html.spec.whatwg.org/multipage/browsers.html#unloading-documents):

"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."

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

Interoperability and Compatibility Risk

Edge: No signals
Firefox: Shipped in Firefox 44 (https://bugzilla.mozilla.org/show_bug.cgi?id=636905)
Safari: In development (https://trac.webkit.org/changeset/214277/webkit), though their version currently is page-oriented rather than frame oriented.
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.