WebKit should disallow beforeunload alerts from web pages users have never interacted with.
<rdar://problem/23798897>
Created attachment 305048 [details] WIP patch
https://html.spec.whatwg.org/multipage/browsers.html#prompt-to-unload-a-document (Step 8): """ 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. """
Created attachment 305057 [details] WIP patch
Created attachment 305063 [details] Patch
Comment on attachment 305063 [details] Patch Attachment 305063 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3379827 New failing tests: fast/events/beforeunload-alert-user-interaction2.html fast/loader/show-only-one-beforeunload-dialog.html http/tests/misc/iframe-beforeunload-dialog-matching-ancestor-securityorigin.html fast/events/beforeunload-alert-user-interaction.html fast/loader/form-submission-after-beforeunload-cancel.html http/tests/misc/iframe-beforeunload-dialog-not-matching-ancestor-securityorigin.html
Created attachment 305078 [details] Archive of layout-test-results from ews124 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews124 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 305101 [details] Patch
Comment on attachment 305101 [details] Patch Attachment 305101 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/3388119 New failing tests: http/tests/misc/iframe-beforeunload-dialog-matching-ancestor-securityorigin.html http/tests/misc/iframe-beforeunload-dialog-not-matching-ancestor-securityorigin.html fast/loader/form-submission-after-beforeunload-cancel.html fast/loader/show-only-one-beforeunload-dialog.html
Created attachment 305108 [details] Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.11.6
Created attachment 305116 [details] Patch
Created attachment 305118 [details] Patch
Comment on attachment 305118 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=305118&action=review Looks good. I had a question about whitespace in the test file, but nothing critical. > LayoutTests/http/tests/misc/iframe-beforeunload-dialog-not-matching-ancestor-securityorigin.html:16 > + // Simulate a user interaction with the page so that the beforeunload alert shows. The indent on this comment looks strange. Is that what you intended? Or did we get a tab in the file?
Created attachment 305121 [details] Patch
Comment on attachment 305121 [details] Patch Clearing flags on attachment: 305121 Committed r214277: <http://trac.webkit.org/changeset/214277>
All reviewed patches have been landed. Closing bug.
I believe the heuristic needs to include an active Media Capture session. When the user entrusts the site with "permanent" access to the microphone and/or camera, the site no longer requires an interaction before it can launch a Media Capture session (e.g., WebRTC call). Under the current definition of activity a click or a keypress is required, which consequently means that if the person is participating in a WebRTC call, they can accidentally leave an active call by pressing F5 key, or closing the wrong tab, for example. Furthermore, the presence of onbeforeunload prompt will be inconsistent between sessions (the first time, user might see it because they have muted their audio prior to accidentally closing the tab, then the second time they would not see the prompt, as they haven't interacted with the page, leading them to believe that the site is at fault for not showing the prompt). If the check for an active Media Capture session doesn't seem sufficient, session duration check may also be added. For example, a minimum session duration of 10 seconds may be used. This would allow users to quickly close the tab if they see content that they don't expect to see, while still preventing accidental reloads that may lead to loss of data. An example of such data loss is a file transfer via RTC Data Channel, when a reload would reset the download progress, potentially leading to irrecoverable loss of data, if for example the transfer was initiated by sender pasting a screenshot from the clipboard. This proposal is cross-posted on Chromium and Firefox bug trackers.
(In reply to teodor.atroshenko from comment #17) > I believe the heuristic needs to include an active Media Capture session. > When the user entrusts the site with "permanent" access to the microphone > and/or camera, the site no longer requires an interaction before it can > launch a Media Capture session (e.g., WebRTC call). > > Under the current definition of activity a click or a keypress is required, > which consequently means that if the person is participating in a WebRTC > call, they can accidentally leave an active call by pressing F5 key, or > closing the wrong tab, for example. Furthermore, the presence of > onbeforeunload prompt will be inconsistent between sessions (the first time, > user might see it because they have muted their audio prior to accidentally > closing the tab, then the second time they would not see the prompt, as they > haven't interacted with the page, leading them to believe that the site is > at fault for not showing the prompt). > > If the check for an active Media Capture session doesn't seem sufficient, > session duration check may also be added. For example, a minimum session > duration of 10 seconds may be used. This would allow users to quickly close > the tab if they see content that they don't expect to see, while still > preventing accidental reloads that may lead to loss of data. An example of > such data loss is a file transfer via RTC Data Channel, when a reload would > reset the download progress, potentially leading to irrecoverable loss of > data, if for example the transfer was initiated by sender pasting a > screenshot from the clipboard. > > This proposal is cross-posted on Chromium and Firefox bug trackers. Please file a new bug to track this remaining issue, and relate it to this bug. Thanks!