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

[Darin Fisher]

On Mon, Jun 27, 2011 at 1:40 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 26.06.2011, в 19:37, Sreeram Ramachandran написал(а):
>
> >> I'm not sure if historically browsers were often taking the liberty of
> crippling widely used features in this way. We didn't kill marquee, for
> instance. For another example, I know that a lot of users dislike animated
> GIFs, and yet we haven't removed support for those.
> >
> > Yet, we killed the blink tag and block popups. I don't think there's a
> > clear consistency here. Some things we deem to have crossed the line,
> > some we don't. In this case, Ian Hickson has suggested that blocking
> > alerts might be worth codifying into the standard
> > (https://bugs.webkit.org/show_bug.cgi?id=56397#c15).
>
> These examples are both somewhat different from blocking alerts as
> proposed:
> - Killing blink hardly removed any semantic meaning from pages.
> - Killing pop-ups did, so browsers have super accessible preferences and/or
> notifications for that. Note how Safari has the preference right in
> application menu.
>
> Perhaps the pop-up preference should be extended (and renamed) to cover the
> proposed behavior?
>
> - WBR, Alexey Proskuryakov
>
>

I don't understand the comparison you are making.  Popups are/were way more
common
than alerts generated from unload.  Way, way more common.

You mentioned marquee earlier.  That was only added by the Gecko engineers
because
their arms were twisted by management.  So sad.  There are plenty of other
IE'isms that
we did not implement, despite suffering web compat problems.

I'm pretty surprised that you are so concerned about this change.  It seems
like we have
learned that alerts in unload handlers are not very common.  Yes, they are
more common
than expected, but upon closer inspection the usage is poor (trying
to prevent users from
leaving a site).

For multi-process browsers, we see a big benefit to be had by disallowing
these dialogs.
It would potentially allow us to hide tabs immediately when the user closes
them.  We
would no longer need to keep the tab visible while we wait for the unload
handler to run.
Keep in mind that in a multi-process browser, the tab being closed could be
bound to a
process that is entirely swapped out.  Paging it in to run unload handlers
could be very
costly.  Alternative solutions, like bringing the hidden tab back into view
when it pops up
an alert, are not satisfactory either.  That leads to ripping the user's
focus away from what
they want to do next.  That's not good UI.

I think we can make this behavior a Setting, and then certainly each
embedder of WebKit
can decide how prominently to surface this option.  For Chrome, we'll
probably either make
it be a command line flag, or we would just leave out the option entirely.

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110627/d35b787e/attachment.html>