[webkit-dev] Disallowing modal dialogs during unload events
mjs at apple.com
Thu Apr 7 10:54:00 PDT 2011
Is there data on:
- The user impact of modal dialogs being fired from before unload, unload or page hide - how often does this happen?
- The Web compatibility impact of removing this functionality (are the sites that do it using it for seemingly legitimate reasons)?
I can think of two ways to gather the data:
1) Add some form of opt-in tracking to see how often users hit a modal dialog during an unload event, and sites where this is done, so we could determine if it causes breakage.
2) Run automated Web crawlers to find this out.
Since we have a potential tradeoff between Web compatibility and usability, it would be good to get some data so that we can weigh the tradeoff.
Side note: when I see a dialog upon leaving a webpage, it is almost always the beforeunload dialog. I'm not sure I have ever seen a regular alert, prompt, confirm, or showModalDialog when leaving the page. This is part of why I'd like to see data. Would we be solving a real problem with this change, or just a theoretical one?
On Apr 6, 2011, at 4:37 PM, Sreeram Ramachandran wrote:
> We'd like to disallow modal dialogs (i.e., those arising from calls to
> alert, confirm, prompt or showModalDialog) during unload events
> (beforeunload, unload and pagehide) . Chromium wants to do this
> . Since this affects web compatibility, I'd like to get agreement
> from the other webkit ports as well.
> The benefits are:
> + Fewer annoyances for users who are trying to leave a page.
> + In the case of tab close, allows the browser to hide the tab before
> it has finished running the unload or pagehide event handlers (doesn't
> apply to beforeunload); gives the impression of better performance.
> This doesn't affect returning a non-null value from beforeunload; that
> will still cause the browser to show the stay-or-leave dialog. We
> think that is sufficient to satisfy legitimate needs to warn the user
> about data loss, etc.
> Outside webkit, this has been discussed on whatwg, but without a
> definite conclusion . Firefox seems to be considering this as well
> All in favour, say aye!
>  https://bugs.webkit.org/show_bug.cgi?id=56397
>  http://code.google.com/p/chromium/issues/detail?id=68780
>  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025080.html
>  https://bugzilla.mozilla.org/show_bug.cgi?id=391834
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev