[whatwg] Navigation events generated during unload

[Boris Zbarsky]

On 10/11/09 9:04 PM, Ian Hickson wrote:
>     http://www.hixie.ch/tests/adhoc/html/navigation/unload/cross-origin/004.html
>
> I couldn't work out what Gecko is doing with it.

I'm not sure what's unclear.  The click starts the load of 
http://another.domain.libpr0n.com/pass and then the form.submit() call 
is ignored, no?  At least that's what I seem to see over here..

> The second is that I also covered onunload. It seems everything that
> applies to one applies to the other; they run back to back as specced in
> HTML5.

I assume you mean onbeforeunload?

In Gecko, onbeforeunload runs when the navigation _starts_ (or when the 
window is being closed, document.open happens, etc); onunload runs when 
the server response is received (so the old document is about to be 
blown away unconditionally).  Is this significantly different in other 
UAs?  Do they actually make a request and wait for a response before 
checking whether the user maybe never wanted to navigate anyway?

> Other than that, I think what I specced matches Gecko. The new text is
> step 3 of the navigation algorithm:
>
>     http://www.whatwg.org/specs/web-apps/current-work/complete.html#navigate

So reading through those steps, I actually have another issue.  Step 10 
seems to imply that javascript: URIs run synchronously.  Gecko used to 
do this, and this was not compatible with what other UAs do, so much, 
nor particularly safe in terms of security bugs.  We quite purposefully 
changed them to run asynchronously (with a single exeption: loads of 
javascript: URIs performed via NPAPI).

Am I reading the spec wrong, or is there a reason for this synchronous 
requirement?

Also, I'm not quite sure what the part about unloading that comes after 
the algorithm you pointed me to means.  Does it mean that once you get 
the response and start parsing the new document you queue a task to 
unload the old one?  That doesn't seem at all right to me, since at this 
point the new document can be running scripts that touch the WindowProxy 
they share...

-Boris