State-preserving atomic move integration #10657

domfarolino · 2024-09-29T19:28:45Z

This PR is a supplementary PR to whatwg/dom#1307. It provides the HTML-overrides for the DOM Standard's "moving steps" extension, to allow pieces of the HTML Standard to react to atomic DOM moves without the use of the "insertion steps" or "removing steps", which by default, intentionally fail to preserve most state. The changes in this PR are inspired by the audit carried out in https://docs.google.com/document/d/1qfYyvdK4zhzloABKeh0K1lHPm-SpnEcsWEE9UdDuoMk/edit.

At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
- https://github.com/web-platform-tests/wpt/tree/master/dom/nodes/moveBefore/tentative (need to mark as non-tentative)
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/issues/40150299
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1923880
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=281223
MDN issue is filed: Document the moveBefore() API mdn/mdn#613 & the impacts-documentation label
The top of this comment includes a clear commit message to use.

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

/custom-elements.html ( diff )
/embedded-content.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/images.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/media.html ( diff )

source

smaug---- · 2024-11-08T01:23:19Z

source

@@ -72810,7 +72874,10 @@ customElements.define("x-foo", class extends HTMLElement {
   <li><p>When it <span>becomes disconnected</span>, its <code data-x="">disconnectedCallback</code>
   is called, with no arguments.</p></li>

-   <li><p>When it is <span data-x="concept-node-adopt">adopted</span> into a new document, its <code
+   <li><p>When it is <span data-x="concept-node-move-ext">moved</span>, its <code
+   data-x="">connectedMoveCallback</code> is called, with no arguments.</p></li>


Shouldn't callback get the old subtree owner as an argument, so that one can know easily where one was.

This would require holding a reference to the old tree which might be gone by the time the CE callbacks are fired. Perhaps we can consider this as a future enhancement? I think we should be able to do that in a compatible way.

We've generally been quite conservative with supplying context to custom element callbacks and nobody has complained so I agree we should continue that trend.

Can this comment be resolved?

annevk

I don't think you mentioned connectedMoveCallback everywhere connectedCallback is mentioned (and it's relevant).

https://html.spec.whatwg.org/#custom-element-reactions
https://html.spec.whatwg.org/#element-definition (this one seems especially important)
It could do with some examples as well.

source

noamr · 2024-12-03T10:40:08Z

I don't think you mentioned connectedMoveCallback everywhere connectedCallback is mentioned (and it's relevant).

https://html.spec.whatwg.org/#custom-element-reactions

This was there already, see https://whatpr.org/html/10657/custom-elements.html#custom-element-reactions ("When it is moved"). Not sure what's missing?

https://html.spec.whatwg.org/#element-definition (this one seems especially important)

Done

It could do with some examples as well.

Added non-normative note and an example

domenic · 2024-12-06T04:10:22Z

Seems like #10828 should be addressed here too?

domfarolino · 2024-12-09T23:18:06Z

Seems like #10828 should be addressed here too?

I think it needs to be done separately; I've uploaded #10840.

… flag

This reverts commit f6e9fbe.

…ons from removing steps

annevk · 2024-12-19T08:03:03Z

source

-     data-x="">attributeChangedCallback</code>" → null ]».</p>
+     null, "<code data-x="">connectedMoveCallback</code>" → null, "<code
+     data-x="">adoptedCallback</code>" → null, "<code data-x="">attributeChangedCallback</code>" →
+     null ]».</p>


The order here is different from the order in list above. After adopted seems reasonable?

To me as well. Done.

smaug---- · 2024-12-19T15:14:14Z

source

+  <var>oldParent</var>, are:</p>
+
+  <ol>
+   <li><p>If <var>movedNode</var>'s next sibling was an <code>img</code> element and


"was"? So somehow this algorithm needs to get the old sibling as argument?

Hmm yes I guess, but the same goes for the removing steps which pre-date this PR and this API. I think fixing that is best left to a follow-up where we evaluate and perhaps overhaul the inputs to these steps.

For example, we could hack together a single parameter hot fix for this hook, but that's not ideal. Rather we need to do something consistent with what's desired in whatwg/dom#1288, where we teach the various hooks to take in a bundle of contextual information (ChildrenChange and ContainerNode in Chromium).

So I think I'd prefer to fix this and removing steps in one swoop after this, since it's easy, ensures nothing diverges, and this doesn't make the problem any worse. How does that sound?

Furthermore, I am actually skeptical that the spec has been doing the right thing in this case anyways. For example, Chromium doesn't track the "old next sibling" of the removed source, and trigger a relevant mutation on it. It triggers relevant mutations on all image children of the picture (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_picture_element.cc;l=26-29;drc=a7096322ab1e5c9e70ae7b773faed492ed8461cb) so maybe implementations are compatible with that, and we can simplify all of this anyways. Regardless, I'd prefer it not block this.

This CL ships the `ParentNode#moveBefore` API to Chrome stable, targeting M133. See: - https://chromestatus.com/feature/5135990159835136 - https://groups.google.com/a/chromium.org/g/blink-dev/c/YE_xLH6MkRs - https://issues.chromium.org/issues/40150299 - whatwg/dom#1255 - whatwg/dom#1307 - whatwg/html#10657 R=chrishtr, masonf, nrosenthal Bug: 40150299 Change-Id: I005f1db250d731d6845b5238048bbd0b90b20c81 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6112499 Reviewed-by: Noam Rosenthal <[email protected]> Reviewed-by: Mason Freed <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/main@{#1400559}

domfarolino mentioned this pull request Oct 10, 2024

Introduce moveBefore() state-preserving atomic move API whatwg/dom#1307

Open

19 tasks

smaug---- reviewed Nov 8, 2024

View reviewed changes

source Show resolved Hide resolved

smaug---- reviewed Nov 8, 2024

View reviewed changes

domfarolino requested a review from annevk November 20, 2024 21:52

domfarolino marked this pull request as ready for review November 20, 2024 21:52

domfarolino added impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation addition/proposal New features or enhancements labels Nov 20, 2024

annevk reviewed Nov 26, 2024

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

source Outdated Show resolved Hide resolved

domfarolino requested review from annevk and smaug---- November 28, 2024 17:06

past mentioned this pull request Dec 5, 2024

Upcoming WHATNOT meeting on 2024-12-05 #10805

Closed

domfarolino and others added 16 commits December 17, 2024 11:10

State-preserving atomic move integration

31a455a

Details + autofocus + frame

a7f520c

Add HTML element moving steps override

cbae5b2

media + option + optgroup

749d57d

Revert most or all usages of state-preserving atomic move in progress…

80edc73

… flag

Spacing

9be6d21

Remove extra newlines

31cf298

Use move steps instead of the flag

f8db942

Add <img> and <source> relevant mutations back

c53b01c

Move enqueing to DOM spec, but include fallback

7e2f398

Listed form element owner reset

0912c42

Form owner reset note

b8d910d

Remove Document flag

7270c09

Reset focus when refocusing document with a moved element

afa512a

Revert "Reset focus when refocusing document with a moved element"

114946e

This reverts commit f6e9fbe.

Remove legacy parser-inserted check, and add form owner reset conditi…

0aec3af

…ons from removing steps

domfarolino and others added 4 commits December 17, 2024 11:10

Other annevk comments

6c6e281

More nits

27ff552

Add hook and example for connectedMoveCallback

2cc804b

Remove newlines

9ee1673

domfarolino force-pushed the atomic-move-patches branch from 05e204b to 9ee1673 Compare December 17, 2024 16:19

domfarolino added 2 commits December 17, 2024 11:20

Formatting and wrapping

6423bfa

Correct a few links and formatting things

ded78da

annevk reviewed Dec 19, 2024

View reviewed changes

smaug---- reviewed Dec 19, 2024

View reviewed changes

domfarolino mentioned this pull request Dec 20, 2024

Document the moveBefore() API mdn/mdn#613

Open

domfarolino added 2 commits December 20, 2024 17:15

Change callback ordering

261d8f6

Wrapping and formatting nits

622dd40

domfarolino requested review from annevk and smaug---- December 20, 2024 22:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

State-preserving atomic move integration #10657

State-preserving atomic move integration #10657

domfarolino commented Sep 29, 2024 •

edited by pr-preview bot

Loading

smaug---- Nov 8, 2024

noamr Nov 20, 2024

annevk Dec 6, 2024

domfarolino Dec 20, 2024

annevk left a comment

noamr commented Dec 3, 2024 •

edited

Loading

domenic commented Dec 6, 2024

domfarolino commented Dec 9, 2024

annevk Dec 19, 2024

domfarolino Dec 20, 2024

smaug---- Dec 19, 2024

domfarolino Dec 20, 2024

State-preserving atomic move integration #10657

Are you sure you want to change the base?

State-preserving atomic move integration #10657

Conversation

domfarolino commented Sep 29, 2024 • edited by pr-preview bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

noamr commented Dec 3, 2024 • edited Loading

domenic commented Dec 6, 2024

domfarolino commented Dec 9, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domfarolino commented Sep 29, 2024 •

edited by pr-preview bot

Loading

noamr commented Dec 3, 2024 •

edited

Loading