Collapse range before mutations in deleteContents and extract

[stevenobiajulu]

Collapse range before mutations in deleteContents and extract

Move the step that sets the range's start and end to (newNode, newOffset) from after DOM mutations to before them, in both deleteContents() and the extract algorithm. The DOM's built-in live range maintenance mechanisms (live range pre-remove steps and replace data range adjustments) keep the range valid through subsequent operations. Collapsing after mutations is unreliable because script can run during removal (via removing steps) and modify the DOM, invalidating the pre-computed values.

Fixes #1446.

---

• At least two implementers are interested (and none opposed):
  • Mozilla (smaug----, Mozilla-affiliated GitHub account, opened https://dom.spec.whatwg.org/#dom-range-deletecontents may collapse the Range to an invalid position #1446)
  • Chromium (shipped fix in CL 7615530, WPT tests merged in Fix Range::extractContents() out-of-bounds extraction bug web-platform-tests/wpt#58132)
• Tests are written and can be reviewed and commented upon at:
  • Add tests for Range collapse ordering in deleteContents/extractContents web-platform-tests/wpt#58008
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/486922855
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=2018839
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=308549
• MDN issue is filed: Update Range.deleteContents() and Range.extractContents() docs for collapse-before-mutations change mdn/content#43230
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

[annevk]

Thanks for fixing this. Let's remove the elaborate notes and put a variant of them in the commit message.

[stevenobiajulu]

@annevk Updated per your review — removed the explanatory notes from both algorithms. The rationale is in the commit message. Also updated the implementer interest checklist.

[stevenobiajulu]

@annevk Thanks for the review! It looks like the Participation check is pending because our organization (UseJunior) hasn't been verified yet. Happy to provide anything that's needed on our end to move that along.

[annevk]

I would like @smaug---- to double check as well since he filed the original issue.

I saw that you filed browser bugs but I think browsers already handle this correctly. You can execute script during removal by using a pagehide listener in an <iframe> element's child document and making sure the <iframe> element gets removed if you want to double check. Only if that demonstrates something I think new tests would be warranted.

[stevenobiajulu]

I ran the empirical test. @annevk you're right — all three browsers already implement the corrected behavior.

Test structure

container > [p#before(0), trigger(1), p#inside(2), p#sentinel(3)]
Range: (container, 1) → (container, 3)

The mutation callback removes p#before (at index 0, before the range's start boundary) while the operation is executing. Under the old spec, collapse(container, 1) would be applied after this removal, overwriting the live-range adjustment with a stale offset. Under the new spec the range collapses first, so the live-range machinery tracks the removal and produces startOffset: 0. The observable difference is startOffset: 0 (new spec) vs startOffset: 1 (old spec).

Results — Chrome 133, Firefox 135, Safari 18

Track	Trigger mechanism	Operation	startOffset	Verdict
A	disconnectedCallback (custom element)	deleteContents	0 (all three)	✅ new-spec behavior
A	disconnectedCallback (custom element)	extractContents	0 (all three)	✅ new-spec behavior
B	pagehide/unload in iframe srcdoc	deleteContents	0 (all three)	✅ new-spec behavior
B	pagehide/unload in iframe srcdoc	extractContents	0 (all three)	✅ new-spec behavior

Track A: disconnectedCallback fired synchronously mid-operation in all three browsers (not deferred past the [CEReactions] boundary on deleteContents() as I'd initially worried — reactions flush when each internal remove() completes).

Track B: pagehide and unload both fired synchronously in all three browsers including Firefox, which surprised me given the HTML spec's "without any unload events firing" language and Bugzilla #1850228. That bug may describe a different scenario.

Screenshots attached.
Chrome:

Safari:

Firefox:

What this means for the open items

• The spec change is a correctness clarification, not a fix for a bug in shipping browsers. I'll update the filed browser bugs to note that.
• On the WPT tests in #58008: given that there's nothing for browsers to fix, I'm happy to close that PR. Alternatively the static collapse-position tests could stay as regression guards for the spec ordering itself — up to you.

[smaug----]

Looks good

[annevk]

Thanks again @stevenobiajulu!