W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 05 Jan 2009 12:04:35 -0500
Message-ID: <49623DA3.7020802@mit.edu>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
CC: public-webapps@w3.org

Giovanni Campagna wrote:
> What if we follow completely Andrew's proposal? That is, we allow 
> cancellation of beforeunload events, but we add an UI control that may 
> be used to froze JS (in HTML5 terms), preventing a further beforeunload 
> to be handled and canceled.

That places UI requirements on UAs, which restricts innovation in the UI 
(which is where UAs should be innovating).

It also adds what I see as unnecessary complexity to accomplish 
something that onbeforeunload already accomplishes.

> This control would be useful also in case of infinite loops or 10'000 
> alert windows: user presses STOP and JS is disabled temporary

Again, this is where UAs should be competing.  Some already provide 
precisely such protection in infinite loop cases.

>     Seems to me like the subframe should just send the messages in this
>     situation.
> 
> What for? If the whole tab is closed, there will be no more message 
> handler, so there is no reason to send a message

The event is firing _before_ the closing has happened, so there is in 
fact a message handler, which may wish to save state or whatnot.

Also, closing doesn't mean the whole app is gone (e.g. the closure of a 
window opened via window.open may well wish to communicate something to 
the opener).

-Boris
Received on Monday, 5 January 2009 17:05:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT