Insertion point for script@onload

In step 8 of <http://www.whatwg.org/specs/web-apps/current-work/#running-a-script>,
the spec adds external scripts to the
<http://www.whatwg.org/specs/web-apps/current-work/#set-of-scripts-that-will-execute-as-soon-as-possible>.
 When the fetching algorithm is complete, the spec invokes
<http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block>.
 However, that sequence of steps does not save the current insertion
point (among other things), which seems very unlikely to be compatible
with the web.

In implementing the above requirement in WebKit, we assumed the spec
meant to invoke
<http://www.whatwg.org/specs/web-apps/current-work/#scriptTagParserResumes>,
which saves the current insertion point (and does other things that
would make sense at that point).  Should we change the spec to say
this explicitly?

In double-checking our work with the HTML5 parser implementation in
Minefield, we noticed that Minefield handles this case slightly
different (likely due to the spec ambiguity above).  In particular,
when the page calls document.write from the load event of a script
tag, Minefield seems to believe there is no current insertion point
and blows away the entire document:

http://trac.webkit.org/export/LATEST/trunk/LayoutTests/fast/tokenizer/write-on-load.html

Under the above interpretation of the spec, the load event shares the
same insertion point record as the external script itself, resulting
in the numerals in that test being printed in order from 1 to 7.  That
behavior appears to match the legacy WebKit and Firefox behavior and
is, therefore, likely compatible with the web.

Adam

Received on Tuesday, 22 June 2010 08:49:40 UTC