Created attachment 481650 [details] test ContainerNode::moveBefore() runs no Style::ChildChangeInvalidation, for either the old parent or the new one. insertBefore(), appendChild() and removeChild() all wrap the DOM change in one. Since 315405@main, Node::movingSteps() invalidates the moved subtree. But nothing invalidates the parents or their other children, so every selector that depends on the child list keeps its old result after a move. The attached test moves an element with moveBefore() and checks the result. With ?append it uses append() instead (and passes). This is probably also why dom/nodes/moveBefore/focus-within.html fails ":focus-within should be eventually up to date when moving to a subtree that would become inert via style". The inertness there comes from :has(button) on the new parent. moveBefore() already builds both child changes, with makeChildChangeForMoveRemoval() and makeChildChangeForMoveInsertion(), but only passes them to childrenChanged(). Running a Style::ChildChangeInvalidation around each half of the move would fix this, with one catch. ChildChange::isInsertion() returns false for ElementMovedInto, TextMovedInto and NonContentsChildMovedInto. ChildChangeInvalidation relies on it to choose before- or after-change invalidation, and for :empty. Other childrenChanged() overrides read isInsertion() too, so style needs its own answer for the move types rather than a change to isInsertion(). Bug 317287 is about doing less work for the moved subtree itself, which is a separate question. There is no WPT for this yet; one in dom/nodes/moveBefore/ along the lines of the attached test would cover it.