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

2009/1/5 Boris Zbarsky <bzbarsky@mit.edu>

> Giovanni Campagna wrote:
>
>> Probably treating the onbeforeunload as a real cancelable event
>>
>
> But the key is that the page must not be able to prevent navigation away
> from itself without explicit OK by the user.  In other words, while the UA
> needs to be able to cancel the unload, the page has no need to.  That
> ability already exists with onbeforeunload.
>
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.
This control would be useful also in case of infinite loops or 10'000 alert
windows: user presses STOP and JS is disabled temporary


>
>  One may attach a onbeforeunload to a frame, and would like to know if only
>> its javascript context is going to
>> disappear, instead of the whole tab being destroyed, so it can send
>> messages to parent window and have them read and handled
>>
>
> There's no difference from navigating the subframe or removing the subframe
> from the parent DOM in terms of the script context going away, yet they'd be
> treated differently in Andrew's proposal.
>
> 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