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
