Steps to reproduce the problem

1. Define a custom element without a “connectedMoveCallback”.
2. Create an instance of that element and add to a connected DOM tree.
3. Change the location of that element the “moveBefore” API within the same connected tree.
4. Note that the disconnectedCallback gets called.

Problem Description

As of writing, it seems that the behavior of the “moveBefore” API on a custom element’s lifecycle callbacks is dependent on the existence of those lifecycle callbacks. I.e., if you define connectedMoveCallback on a custom element — it will behave differently than if connectedMoveCallback is not defined. As a developer, I would not expect such a behavioral fork as it does not seem to be part of the specification (https://github.com/whatwg/dom/pull/1307).

Additional Comments

Thanks so much for adding this feature — it’s incredibly helpful to have a way to move elements around without resetting state! I’ve attached the “variations.txt” as described above and I’ve uploaded a simple “move-before.html” file that demonstrates the exact issue I’m seeing.

Thanks again!

Summary

Behavior of “moveBefore” should not change based on “connectedMoveCallback” existence in element.

Custom Questions

Which component does this fall under?

Blink>DOM

Does this work in other browsers?

Not sure - I don't know

Additional Data

Category: API
Chrome Channel: Stable
Regression: No