Intent to Ship: Change beforeunload handler dialog condition

[Di Zhang]

Contact emails

dizh...@chromium.org

Specification

https://html.spec.whatwg.org/multipage/browsing-the-web.html#checking-if-unloading-is-user-canceled

Summary

Change beforeunload handler to show confirm dialog when preventDefault() gets called.

Blink component

Blink>DOM

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Now, if website is calling `preventDefault()` on a beforeunload event, it will show the confirmation dialog to cancel the unload event. Before, if website is calling `preventDefault()` on a beforeunload event, it will not show the confirmation dialog and navigate.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive
1. https://bugs.chromium.org/p/chromium/issues/detail?id=866818
2. https://stackoverflow.com/questions/9626059/window-onbeforeunload-in-chrome-what-is-the-most-recent-fix
3. https://stackoverflow.com/questions/1119289/how-to-show-the-are-you-sure-you-want-to-navigate-away-from-this-page-when-ch

Other signals:

Ergonomics

There are no other APIs that this feature will be used in tandem with.

Activation

It should not be challenging for developers to take advantage of this feature immediately.

Security

There are no security risks for this feature.

WebView application risks

There is no high risk for webview.

Debuggability

DevTools support for this feature is not needed.

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

Yes

All platforms support the cancel dialog.

Is this feature fully tested by web-platform-tests?

Yes

Flag name

BeforeunloadEventCancelByPreventDefault

Requires code in //chrome?

False

Estimated milestones

112

Anticipated spec changes

There are no open spec issue and the spec already says that calling preventDefault() on beforeunload event should show the cancel dialog.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4968823574233088

This intent message was generated by Chrome Platform Status.

[Manuel Rego Casasnovas]

LGTM1

This aligns us with the rest of browsers, thanks for fixing it.

Cheers,
Rego

On 21/02/2023 19:24, Di Zhang wrote:
>
> Contact emails
>
> dizh...@chromium.org <mailto:dizh...@chromium.org>
>
>
> Specification
>
> https://html.spec.whatwg.org/multipage/browsing-the-web.html#checking-if-unloading-is-user-canceled <https://html.spec.whatwg.org/multipage/browsing-the-web.html#checking-if-unloading-is-user-canceled>

>
>
> Summary
>
> Change beforeunload handler to show confirm dialog when preventDefault()
> gets called.
>
>
>
> Blink component
>
> Blink>DOM

> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM>

>
>
> TAG review
>
> None
>
>
> TAG review status
>
> Not applicable
>
>
> Risks
>
>
>
> Interoperability and Compatibility
>
> Now, if website is calling `preventDefault()` on a beforeunload event,
> it will show the confirmation dialog to cancel the unload event. Before,
> if website is calling `preventDefault()` on a beforeunload event, it
> will not show the confirmation dialog and navigate.
>
>
>

> /Gecko/: Shipped/Shipping
>
> /WebKit/: Shipped/Shipping
>
> /Web developers/: Positive
> 1. https://bugs.chromium.org/p/chromium/issues/detail?id=866818
> <https://bugs.chromium.org/p/chromium/issues/detail?id=866818>
> 2. https://stackoverflow.com/questions/9626059/window-onbeforeunload-in-chrome-what-is-the-most-recent-fix <https://stackoverflow.com/questions/9626059/window-onbeforeunload-in-chrome-what-is-the-most-recent-fix>
> 3. https://stackoverflow.com/questions/1119289/how-to-show-the-are-you-sure-you-want-to-navigate-away-from-this-page-when-ch <https://stackoverflow.com/questions/1119289/how-to-show-the-are-you-sure-you-want-to-navigate-away-from-this-page-when-ch>
>
> /Other signals/:

>
>
> Ergonomics
>
> There are no other APIs that this feature will be used in tandem with.
>
>
>
> Activation
>
> It should not be challenging for developers to take advantage of this
> feature immediately.
>
>
>
> Security
>
> There are no security risks for this feature.
>
>
>
> WebView application risks
>
> There is no high risk for webview.
>
>
> Debuggability
>
> DevTools support for this feature is not needed.
>
>
>
> Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> All platforms support the cancel dialog.
>
>
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

>
> Yes
>
>
> Flag name
>
> BeforeunloadEventCancelByPreventDefault
>
>
> Requires code in //chrome?
>
> False
>
>
> Estimated milestones
>
> 112
>
>
>
> Anticipated spec changes
>
> There are no open spec issue and the spec already says that calling
> preventDefault() on beforeunload event should show the cancel dialog.
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/4968823574233088
> <https://chromestatus.com/feature/4968823574233088>
>
> This intent message was generated by Chrome Platform Status

> <https://chromestatus.com/>.
>
> --
> 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+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSS7eAfjeL8MZfTuVDGZR5Lg%3DPquwoUeF91fNJqV1vs%3DHsKZQ%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSS7eAfjeL8MZfTuVDGZR5Lg%3DPquwoUeF91fNJqV1vs%3DHsKZQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Yoav Weiss]

Do you know the reasons for not prompting the user in that case?

I wonder if there's some history here. +Carlos IL +Emily Stark +Mike West - do y'all know? 

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/d0b0743d-b484-f7e6-4d84-5e4960bfddb5%40igalia.com.

[Carlos IL]

I'm not familiar with the history of not allowing preventDefault here (and I think I've reached the limits of git hyperblame trying to dig for it), so I'll let Mike or Emily correct me if I'm missing something, but looking at the current implementation I don't think there's anything a site could abuse from using preventDefault that they couldn't already do by triggering the dialog by setting a return value.

-Carlos

[Rick Byers]

Oh! If all we're doing is bringing behavior already possible through the return value to preventDefault then yeah I agree that was probably just an oversight. I can't imagine there being any good reason to have the return value but not preventDefault wired up. LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfXqwUeoK1cuW1i7%3DrD%2BCxYc4hNNUyR7H5C%3DsDZsz%2BxStQ%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-oSzv_16FnTRs8P7237B2pV-GyHob5v798B1dup6rjVg%40mail.gmail.com.

[Di Zhang]

Thanks!! Yes, this change is bringing behavior already possible through the return value.