W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] Can we deprecate alert(), confirm(), prompt() ?

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 10 Jan 2012 16:51:09 -0800
Message-ID: <CANMdWTuQfVjX4adsDmu2wkLgLKkjs14C8ns9xacRvzCovR9XfA@mail.gmail.com>
On Tue, Jan 10, 2012 at 2:38 PM, Adam Barth <w3c at adambarth.com> wrote:

> On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 14 Jun 2011, Adam Barth wrote:
> >> On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov <ap at webkit.org>
> >> wrote:
> >> > 28.02.2011, ? 21:38, Ojan Vafai ???????(?):
> >> >> FWIW, chromium is planning on experimenting with disallowing modal
> >> >> dialogs during the beforeunload/unload events.
> >> >> http://code.google.com/p/chromium/issues/detail?id=68780
> >> >
> >> > What is the big difference between alerts from unload and alerts in
> >> > general? Alerts are not particularly useful for anything besides
> >> > debugging, and pagehide/unload handlers is a place where they I've
> >> > found them particularly useful for debugging.
> >> >
> >> > Do we have at least anecdotal evidence that many sites are showing
> >> > alerts from unload? When I'm seeing a site that tries to prevent me
> >> > from leaving it, it's always by returning a string from
> >> > onbeforeunload.
> >>
> >> I believe the motivation is to be able to close tabs quickly.  If a tab
> >> doesn't register for any unload / beforeunload events, the tab can be
> >> kill instantly.  If the site registers for unload but not beforeunload,
> >> then, today, we need to wait for JavaScript to execute before closing
> >> the tab.  Without the ability to trigger alert and friends during
> >> unload, we can hide the tab instantly and unload it in the background.
> >>
> >> We have lots of stats for how many tabs would benefit from this
> >> optimization and how much time would be saved.  It's surprisingly large.
> >
> > Any news on this? If Chrome was able to do this, it would be worth
> putting
> > in the spec to give cover to other browsers interested in the same
> > potential performance improvement.
>
> Ojan probably has more concrete data.  I think we got one or two
> complaints, but no major problems.


The only complaint I'm aware of is in http://crbug.com/97206. The bug
comments are confusing. The primary issue there is WebKit not firing
beforeunload/unload from frames in some cases, but there is one comment
about code that calls "confirm" from unload handlers followed by a sync XHR
to save data that now breaks.

Ojan
Received on Tuesday, 10 January 2012 16:51:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC