- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 14 Jul 2009 09:54:31 +0300
- To: Travis Leithead <travil@microsoft.com>
- Cc: Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>, Kirk Sykora <ksykora@microsoft.com>
On Jul 13, 2009, at 20:40, Travis Leithead wrote: > Note, we also tested this with IE8+parser fix we've been looking > into and our result is: > >>> We sometimes succeed and sometimes fail. (I'm guessing it's a >>> timing issue with the script download) >>> When we succeed it looks like Firefox with more whitespace and >>> "Kittens! Budgies!" before "BEFORE ... ... AFTER" instead of after. It seems to me that an HTML5-compliant result shouldn't show "BEFORE... ...AFTER" at all. When the load for the external script- inserted script completes, the script is run from the event loop. Thus, there are no parser stack frames on the call stack and insertion point can't be defined. Therefore, the document.write() from 005a.js implies a document.open() and blows away the original DOM that had "BEFORE... ...AFTER" in it. The reason why this doesn't happen with the old Gecko HTML parser is that it never implies document.open() upon document.write() if there's an active parser. Based on Hixie's notes, I *think* the reason why this doesn't happen in Opera is that Opera runs the script-inserted external script synchronously instead of just scheduling the load and letting the execution happen from the event loop. With my upcoming (though very possibly broken patch), I consistently get Kittens!, but I get Budgies!, too, only if I do something unusual like bother the timing with a debugger or perform a cached navigation back to the page. Also, with my upcoming patch, the page never finishes loading, which seems right because the page has been replaced with a script-created page that never got document.close() called on it. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 14 July 2009 06:55:13 UTC