[whatwg] Navigation events generated during unload

On Sun, 11 Oct 2009, Boris Zbarsky wrote:
> 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..

Why is the form.submit() ignored? It's not ignored in, e.g.:

   http://www.hixie.ch/tests/adhoc/html/navigation/unload/same-origin/004.html


> > 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?

Yes, sorry.


> 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).

Fixed the spec to do this too.


> > 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?

Oops, that's a vestigial bit. The comment is non-normative (and wrong); 
the actual normative text makes javascript: async, only about:blank is 
sync. Fixed.


> 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...

Not sure what you mean here. I've tried to clarify that the new page must 
be active before any scripts run.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 11 October 2009 22:55:06 UTC