[Bug 17880] New: Inserting multiple script elements using a document fragment isn't specified properly

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17880

           Summary: Inserting multiple script elements using a document
                    fragment isn't specified properly
           Product: HTML WG
           Version: unspecified
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: other Hixie drafts (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: contributor@whatwg.org
         QAContact: contributor@whatwg.org
                CC: ian@hixie.ch, hsivonen@iki.fi, mike@w3.org,
                    annevk@annevk.nl, jonas@sicking.cc, www-dom@w3.org


This was was cloned from bug 17529 as part of operation convergence.
Originally filed: 2012-06-18 07:13:00 +0000
Original reporter: Olli Pettay <bugs@pettay.fi>

================================================================================
 #0   Olli Pettay                                     2012-06-18 07:13:09 +0000 
--------------------------------------------------------------------------------
Per HTML spec inserting script element to DOM should execute it immediately
(I'm talking about var s = document.createElement("script"); s.textContent =
"alert('foo')"; document.body.appendChild(s); case)

Unfortunately it isn't clear what should happen when you have several
script elements in a document fragment and insert that document fragment to
DOM.

Gecko seems to execute scripts after all the nodes are in DOM.
This seems to be ok per spec, since nothing prevents to do 
"HTML: An element is said to have been inserted into a document when its root
element changes and is now the document's root element." atomically for several
elements and DOM4 just says
"Insert all nodes in nodes before child or at the end of parent if child is
null."
The behavior Gecko has doesn't cause problems to Mutation Record creation.

Presto and Webkit execute scripts one by one during the document fragment
insertion
but not in the same way. Webkit seems to remove nodes first from the document
fragment,
Presto removes them one by one. (Webkit's follow the spec here)
Anyhow, the tricky thing is that what if some script moves nodes during
insertion.
What kinds of Mutation Records should be created? What should actually happen
to the nodes
which are being inserted to DOM but which some script moves to elsewhere just
before insertion.
================================================================================
 #1   Henri Sivonen                                   2012-06-19 07:15:30 +0000 
--------------------------------------------------------------------------------
When there are nested scripts in the fragment, WebKit and IE10 agree on the
execution order. Gecko doesn't. Presto misbehaves by using the .textContent
instead of the concatenation of child text nodes.
================================================================================
 #2   Olli Pettay                                     2012-06-19 08:21:00 +0000 
--------------------------------------------------------------------------------
(In reply to comment #1)
> When there are nested scripts in the fragment, WebKit and IE10 agree on the
> execution order. Gecko doesn't. Presto misbehaves by using the .textContent
> instead of the concatenation of child text nodes.
This bug isn't about nested scripts ;)
================================================================================
 #3   Jonas Sicking                                   2012-06-19 23:27:42 +0000 
--------------------------------------------------------------------------------
We should absolutely not run scripts half-way through the mutation when a
fragment is inserted. That brings back all the same trouble we had with
mutation events.

The only sane thing, IMO, is to do all the mutations, and then do all actions
which needs to synchronously call out into Javascript, and then return to the
caller.

Anything else is both hellish to implement, and dramatically increases the
amount of edge cases that we need to define (where does insertion happen if
nodes are moved around half-way through the mutation, what happens if more
nodes are added to the fragment as nodes are moved out of it, what happens if a
child was removed from the fragment, but is inserted there again before the UA
inserts it at its new location, and so on)
================================================================================
 #4   Olli Pettay                                     2012-06-19 23:30:35 +0000 
--------------------------------------------------------------------------------
Yup. I fully agree with you.
================================================================================
 #5   Henri Sivonen                                   2012-06-21 06:33:30 +0000 
--------------------------------------------------------------------------------
In addition to a document fragment, the same rules should apply even when
inserting multiple elements at one by inserting an element that has element
descendants.

About the execution order:
The parser executes scripts not in the depth-first order of start tags but in
the depth first order of end tags. Of course, we don't have to be consistent
with that, but worth remembering anyway.
================================================================================
 #6   Ian 'Hixie' Hickson                             2012-06-21 06:37:27 +0000 
--------------------------------------------------------------------------------
Yeah, this isn't defined.

Unless there's a compat reason not to, my inclination is to define execution as
happening after the mutation listeners, in tree order (pre-order, depth-first
traversal).

See also bug 17543.
================================================================================
 #7   Ian 'Hixie' Hickson                             2012-07-12 19:43:14 +0000 
--------------------------------------------------------------------------------
(this will probably use the hook from bug 17530)
================================================================================

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 18 July 2012 07:11:16 UTC