The relevant link is https://html.spec.whatwg.org/#prompt-to-unload-a-document .
onbeforeunload dialogs are used for two things on the Modern Web:
1. Preventing users from inadvertently losing data.
2. Scamming users.
In an attempt to restrict their use for the latter while not stopping the former, we are going to not display the string provided by the web page. Instead, we are going to use a generic string.
Firefox already does this (see the attachment on the bug).
This does not violate the spec. Per https://html.spec.whatwg.org/#prompt-to-unload-a-document, step 7:
"The prompt shown by the user agent may include the string of the returnValue attribute, or some leading subset thereof. (A user agent may want to truncate the string to 1024 characters for display, for instance.)"
The prompt MAY include the string. We would no longer do so.
Users are being harmed by bad actors. This mitigates much of the abuse of the API by bad actors while preserving the data-saving aspects that this API can be used for.
Interoperability and Compatibility Risk
Firefox already does this, https://bugzilla.mozilla.org/show_bug.cgi?id=641509 . We would be following them.
Ongoing technical constraints
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
OWP launch tracking bug
Link to entry on the feature dashboard
This is a change to existing behavior that remains spec-compliant. I don't believe it requires a feature dashboard entry.
Requesting approval to ship?
Rather than show that prompt, would it not be better UX to save that partially typed chat message or comment and restore it later?
For the substitute message, Firefox uses "This page is asking you to confirm that you want to leave - data you have entered may not be saved" which seems suitable enough for both your uses. Presumably the user just typed or sent that message, so they'll usually know what it is. In comparison to other APIs, this prompt is maximally abusive with negligible legitimate uses, so I think a slight loss of fidelity for the semi-legitimate cases is worth stamping out the abuse.
Anecdotally, a lot of folks (incorrectly) think that beforeunload and unload are interchangeable for non-prompting cleanup code, so I suspect most of that 9.18% isn't actually this case, but it would be good to get numbers whether the prompt is actually shown. (Although that too isn't quite right because one might register beforeunload, with the intent to prompt, but only fire the prompt in rare cases. Ideally we'd include that but exclude the sites using it to fire some analytics XHR.)
This isn't proposing to remove the prompt though. It's only proposing to ignore the string in place of a fairly generic one, something Firefox already does.
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.
Can we log the message at event registration time?
I have a question.In my CL to do this, I got some pushback that I wasn't ripping out enough infrastructure, and my initial response was that I wanted to preserve the ability for embedders to make the choice themselves.While it looks like I have approval, it seems like I got more approval than I was intending to ask for. I intended to get approval to do this for Chrome/Chromium, but it seems like people are OK with doing for every Blink/content embedder.Is that the case? Should I remove the ability to specify the message all the way down? Or just remove it from Chromium and let other embedders decide?
In general we don't leave things in for "other embedders", blink is the rendering engine for Chrome and is not a general purpose rendering engine you can use without the rest of our stack.
An update on onbeforeunload strings:This change was committed with https://codereview.chromium.org/1714573002/ at r380755, and will likely ship in M51.I was pointed to Safari 9.1's release notes which notes that Safari is doing this too. This means that this behavior will be in Safari >= 9.1, Firefox >= 4, Chrome >= 51, and Opera >= ? (I'm afraid I don't know the Opera version mappings), so this appears to be the new de-facto standard for handling this.
Available for: OS X Mavericks v10.9.5, OS X Yosemite v10.10.5, OS X El Capitan v10.11 to v10.11.3
Impact: Visiting a malicious website may lead to user interface spoofing
Description: An issue existed where the text of a dialog included page-supplied text. This issue was addressed by no longer including that text.
CVE-2009-2197 : Alexios Fakos of n.runs AG