This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7926 - Undefine insertion point if parser on call stack doing anything other than running script element
Summary: Undefine insertion point if parser on call stack doing anything other than ru...
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2009-10-15 09:01 UTC by Henri Sivonen
Modified: 2010-10-04 13:58 UTC (History)
4 users (show)

See Also:

Attachments

Description Henri Sivonen 2009-10-15 09:01:35 UTC 
Please make the insertion point undefined where the current spec would otherwise make it defined if the HTML parser whose insertion point is in question is on the call stack performing a DOM operation other than running a script element upon </script>.

Rationale:
If document.write() can call into the parser in response to more or less any parser-performed DOM operation (due to XBL bindings attaching to parser-inserted nodes, due to legacy synchronous events firing when stuff is inserted into the DOM), speculative parsing (in the network case) and notification batching (to avoid running the CSS parts of the layout engine on a per-DOM operation basis) become pointlessly hard.
Comment 1 Ian 'Hixie' Hickson 2009-10-21 08:49:01 UTC 
How would you have me handle document.open()ed pages, which always have the insertion point set?
Comment 2 Henri Sivonen 2009-10-21 09:42:17 UTC 
(In reply to comment #1)
> How would you have me handle document.open()ed pages, which always have the
> insertion point set?

I suggest making the undefinition rule in this bug report override the definition rule from the current spec: That is, I propose undefining the insertion point in the document.open() case when the script-created parser itself is on the call stack performing a DOM operation (other than running script upon </script>). The purpose is to keep the implementation sane in the case of XBL constructors, legacy link element insertion events or the SVG load event firing from a script-created parser.

Concretely, I'm asking you to legitimize the !mExecutor->IsFlushing() check in IsInsertionPointDefined() in the patch on
https://bugzilla.mozilla.org/show_bug.cgi?id=503473
Comment 3 Ian 'Hixie' Hickson 2009-10-21 09:50:48 UTC 
I would rather just make there be no way to synchronously run script from the parser other than <script>.

XBL2 doesn't attach synchronously, as far as I can tell.

What are the "legacy link element insertion events"?

Where is the spec for SVG's 'load' event's interaction with the parser? Maybe we can do something specifically for those?