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

[Sreeram Ramachandran]

On Sun, Jun 26, 2011 at 12:10, Adam Barth <abarth at webkit.org> wrote:
> On Sun, Jun 26, 2011 at 11:42 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>> 26.06.2011, в 09:34, Sreeram Ramachandran написал(а):
>>> Briefly, from a histogram we added a while ago, I find that 2.3% of
>>> all users encounter at least one such modal dialog every week. This is
>>> much larger than I expected.
>>
>> Interesting - this is much more than I expected , too. So, authors are widely using alerts in onload, and breaking those would be bad for compatibility. If this change is made, 2.3% of users will suffer every week.
>
> It would be useful to know what fraction of those users would have a
> better experience with this change.  Sreeram, of the example sites
> that you've seen, how many would be improved by suppressing these
> alerts?

Every single manual example of alert I found was of the annoying
variety ("Please don't go!", "Thanks for checking our site!", "Be sure
to click Yes on the next dialog!", etc). None of them add any
functionality. Indeed, how can they? They are just messages with a
single "OK" button to dismiss them.

I did see a couple of confirm() calls in beforeunload. The examples I
found were also annoying ("Are you sure you want to leave? Yes/No"),
but I can imagine those could instead have been more useful ("Do you
want to save some state? Yes/No"). I think if there are indeed such
uses, they can be transformed into  something that returns a non-NULL
value in beforeunload and then saves state.

In fact, I found many more cases where on unload, the pages
automatically cleared some state, set some cookies, sent some pings,
etc., without ever alerting or asking the user. I believe, for
instance, that Gmail does this currently: If you are editing a message
and abruptly close the window, it just saves the draft automatically,
without bothering the user.