[webkit-dev] The case for disallowing alerts in unload, redux

[Sreeram Ramachandran]

On Mon, Jun 27, 2011 at 00:11, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Sun, Jun 26, 2011 at 11:48 PM, Sreeram Ramachandran
> <sreeram at chromium.org> wrote:
>>
>> I think the performance benefit and reduction in code complexity are
>> secondary. Reducing user annoyance is the number one priority.
>
> But websites can annoy users by many other means.  It seems like all we need
> is a "do not show again" checkbox rather than disallowing
> them indiscriminately.

Yes, websites can annoy users in many ways. Shouldn't we disable those
techniques we consider egregious, especially if they add little value
to the user or are universally disliked (cf: examples cited so far:
blink, popups)? In addition, users need the browser's help
particularly when they are trying to quit an annoying page, and the
page just won't let go. We already have the "do not show again"
checkbox. But clearly (from the stats in the original mail), there's
potential to do more.

As I said before, I haven't seen a case of anybody using a
confirm/prompt for a reasonable purpose in beforeunload. Here's an
example of the contrary, a site that pops up an alert in beforeunload:
    http://www.80move.cn/

>> I'd prefer to keep things consistent and just disallow all modal dialogs
>> in all types of unload handlers (beforeunload, pagehide and unload).
>
> Why is that good or necessary?
> beforeunload and unload have very different semantics.  beforeunload is
> fired before a page is unloaded to make the navigation cancelable and
> prepare for unloading the page whereas unload is fired AFTER the page
> dismissal has started.  At this point, the navigation cannot be stopped and
> all script can do is to save states, etc...
> Given these semantics, it seems okay to disallow modal dialogs in unload
> event because the navigation cannot be canceled after unload event is fired
> and, in fact, browser has already started unloading the page. On the other
> hand, disallowing modal dialogs in beforeunload event seems weird to me
> because the navigation can still be canceled and the browser hasn't (and
> shouldn't have) started evicting the page.

I think the difference in semantics between beforeunload and unload is
perfectly captured by the return value. I don't see why other modal
dialogs enter into it. In fact, we've long recognized that people can
abuse beforeunload/unload in various ways and we've taken steps to
mitigate them:

1. Developers have tried to abuse the return string from beforeunload
to confuse users and click on the wrong button. So much so that
Firefox has ended up not showing the return string altogether, which I
think moves the needle too far in the other direction (see the long
list of comments at
https://bugzilla.mozilla.org/show_bug.cgi?id=588292). I think our
compromise of showing the return string, but making the buttons
unambiguous ("Stay/Leave" instead of "OK/Cancel" or "Yes/No") is the
right balance.

2. Developers have tried to put long delays in unload and sleeping
forever (and indeed, avoiding the script-hang-monitor timeout). We've
hacked around them (http://webkit.org/b/29193, http://crbug.com/7823,
https://lists.webkit.org/pipermail/webkit-dev/2009-September/009925.html).

3. Developers try to load resources, navigate to other pages, etc. We
rightly block such attempts from unload. However, there's a legitimate
need to send pings for analytics, so we compromise by allowing image
requests to outlive the page (http://webkit.org/b/30457).

To summarize, each of the above can be considered a legitimate
developer need, but we find that more often than not, they are abused.
In many cases, we have been able to support the legitimate use case by
offering a compromise. I consider disallowing modal dialogs but
allowing the return value to popup the stay-or-leave dialog to be a
similarly good compromise between the needs of developers and users.