- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 05 Jan 2009 12:04:35 -0500
- 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 UTC