Re: Insertion point for script@onload

"Adam Barth" <w3c@adambarth.com> wrote:

> 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.

Is there evidence of sites calling document.write() from the load handler of a script so often that calling document.write() from a script load handler needs to work?

The off-the-main-thread parsing implementation in Minefield makes it necessary to know in advance which points in the network stream are eligible for document.write(). Since establishing a point eligible for document.write() is somewhat complex, it is only done at </script> and only for scripts that don't have defer or async specified in the source. Furthermore, to be able to perform multiple DOM modifications in a script-unsafe batch, the HTML5 parser limits script execution of any kind to well-defined points (</script> mainly plus a couple of other cases that may go away as soon as other parts of Gecko are changed not to expect that behavior).

For these reasons, I've made the parser forbid document.write() from all event handlers. When I did this, the event handler I particularly wanted to prevent from writing was the SVG load event handler. I wasn't thinking of <script onload>. While <script onload> of parser-inserted scripts is guaranteed to fire when the parser is at the </script> safe point (*if* the event fires synchronously!), I'd rather not punch a special hole for that event handler without a compelling use case or site compat requirement. (Also, it seems inconsistent to make load on <script> fire synchronously when load events in general are async.)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 22 June 2010 09:37:27 UTC