[whatwg] window.location aborting the parser and subsequent document.writes

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'