17529 2012-06-18 07:13:09 +0000 Inserting multiple script elements using a document fragment isn't specified properly 2013-03-22 00:10:27 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED FIXED P2 normal --- 17530 1 bugs silviapfeiffer1 annevk contributor hsivonen ian jonas mike public-html-admin public-html-wg-issue-tracking travil www-dom public-html-bugzilla oldest_to_newest 69189 0 bugs 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. 69220 1 hsivonen 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. 69222 2 bugs 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 ;) 69261 3 jonas 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) 69262 4 bugs 2012-06-19 23:30:35 +0000 (In reply to comment #3) > 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. Yup. I fully agree with you. 69310 5 hsivonen 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. 69312 6 ian 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. 69916 7 ian 2012-07-12 19:43:14 +0000 (this will probably use the hook from bug 17530) 70231 8 contributor 2012-07-18 07:11:13 +0000 This bug was cloned to create bug 17880 as part of operation convergence. 74152 9 ian 2012-09-20 19:50:00 +0000 *** Bug 17543 has been marked as a duplicate of this bug. *** 84811 10 travil 2013-03-22 00:10:27 +0000 This was fixed by a previous commit: https://github.com/w3c/html/commit/6afe9c0f52fc4ffc27be7a6c724ec0dd36877c5c