[Bug 9984] [parser] Insertion point for script@onload doesn't match Firefox

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984





--- Comment #8 from Henri Sivonen <hsivonen@iki.fi>  2010-08-31 15:24:20 ---
(In reply to comment #7)
> But presumably you still want the event to allow document.write() when the
> whole thing is happening under document.open()/document.write() calls, right?

Doh. I forgot about that. The premise of my opinion is wrecked. It seems I have
more Gecko script execution hacking ahead. 

> Why is non-parser code setting the insertion point in Gecko? That seems odd.

I reasoned that document.write() is only permitted from parser-inserted
scripts, so the easiest way to disallow it otherwise was to make the execution
of parser-inserted script allow it.

There are several insertion points in Gecko. The parser doesn't know which one
is current. The .write() implementation passes the memory address to the parser
so the address can be used as a script-unique identifier for searching the
right insertion point.

I didn't rewrite the Gecko script execution code for the HTML5 parser. It
seemed more reasonable to keep the old script execution code in place, since
replacing the parser was big enough a change. So the script execution code is
now the old code but a bit evolved. Today, I've been rewriting notable parts of
the script execution code, though, after discovering that it was non-compliant
in a Web-breaking way.

(In general, having a document-owner script loader manage when parser-inserted
scripts block is sadness when a crazy script moves a node to another doc during
the parser so that the parser inserts nodes to another doc while assuming the
scripts get executed in the context of the script loader of the doc the parser
is associated with. Well, more to the point, moving nodes like that is sadness.
I expect things to be quite broken if someone does that...)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 31 August 2010 15:24:25 UTC