[whatwg] window.location aborting the parser and subsequent document.writes
ian at hixie.ch
Mon Feb 13 16:43:15 PST 2012
On Thu, 5 Jan 2012, Henri Sivonen wrote:
> Consider https://bug98654.bugzilla.mozilla.org/attachment.cgi?id=77369
> with the popup blocker disabled.
> Chrome, Opera and IE open a new window/tab and load the Mozilla front
> page into it. Firefox used to but doesn't anymore.
> As far as I can tell, Firefox behaves according to the spec: Setting
> window.location aborts the parser synchronously and the first subsequent
> document.write() then implies a call to document.open(), which aborts
> the navigation started by window.location.
Per spec, aborting the parser doesn't cause document.write() to imply a
call to document.open(). Specifically, it leaves the insertion point in a
state that is defined, but with the parser no longer active, and
discarding any future data added to it.
> Note that in this modified case
> http://hsivonen.iki.fi/test/moz/write-after-location.html (requires a
> click so that there's no need to adjust the popup blocker) the console
> says "before" and "after" but not "later" in Chrome and IE.
That's consistent with the parser being aborted before the "</head>" is
document.write()n. The last "\u003cscript>" never makes it into the
parser, it just falls on the floor.
> Opera says "before" and "after" and then the opener script ends with a
> security error, because write is already a different-origin call, i.e.
> setting window.location has immediately made the document in the new
> window different-origin.
That's definitely wrong, IMHO. Consider if the network responded with a
redirect or something. How can you know what the origin is before the
navigation is far further along?
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg