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
