Re: [whatwg/dom] Side effects due to tree insertion or removal (script, iframe) (#808)

> @domfarolino I mean that the insert operation hasn't completed by the time script executes (there's still another script to insert).

I see. So you would like multiple, synchronously back-to-back insertions (of say, several `<script>` elements) to _not_ invoke script until _all_ insertions are done. I guess there is a question of what "atomic" means here. I can imagine two ways it could work:

 1. Insertion is atomic, **at a per-task level**
    - That is, if a single task calls `document.body.append(script1); document.body.append(script2);`, literally neither script executes until that task (that did the appending) is done. Then both execute in order.
    - This model feels weird. If the developer is explicitly separating the insertion of the two scripts, there is no reason why `script1` shouldn't execute after it has been inserted, but before the second `append()` is called.
 1. Insertion is atomic, **at a per-"insertion call" level**
    - Imagine `document.body.append(script1); document.body.append(fragmentWithTwoScripts);` (see https://github.com/web-platform-tests/wpt/pull/44308)
    - In this model, appending `script1` would call the script's insertion steps, and would not execute the script until the stack is cleared of all ["insertion calls"](https://dom.spec.whatwg.org/#concept-node-insert). So inside the first `append()` (but after the "insertion" algorithm returns), `script1` would immediately run.
    - Next, the document fragment with two scripts would get inserted; this puts an ["insert call"](https://dom.spec.whatwg.org/#concept-node-insert) on the stack. Within that call, we run the [insertion steps](https://dom.spec.whatwg.org/#concept-node-insert-ext) for each node, but none of these are allowed to synchronously invoke script, because a call to "insert" is on the stack. Finally, the top-most "insert" algorithm returns, and just before `append()` returns all scripts that were queued from any "insertion steps" hooks are executed in order.

> From that perspective I like the staging that I think Gecko has. Whereby you complete insertion and then have another loop/queue for side effects.

I have two comments on this. **First**, I think Gecko's model is fairly desirable, however I think Chrome's is slightly more consistent. Both are pretty much (2) above. Both implementations execute scripts after all have been appended to the DOM (so that earlier scripts can observe later scripts and remove them from the DOM). However Chromium refuses to execute a script that an earlier script removed from the DOM, which I think is consistent with our general policy of not executing scripts that have changed documents (https://github.com/whatwg/html/pull/5575).

**Second**, if we think (2) above is desirable, do we think we can actually change the spec + Safari to align on all of this? For `<script>` elements in particular, it is probably doable since 2/3 implementations _pretty much_ already do some version of this. However generalizing it seems harder, since for at least iframes, ever browser aligns on synchronously firing the `load` event during the HTML element insertion steps. Changing that to be consistent with the model (2) above is almost certainly a compat issue. Thoughts?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/808#issuecomment-1919789975
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/808/1919789975@github.com>