Begin of the insertion_FiledEnd of the insertion Begin of the deletion _N.B. This was filedEnd of the deletion as a Begin of the insertion"hypothetical bug" —End of the insertion Begin of the deletion "hypothetical bug" - an issueEnd of the deletion found with AI tooling. Begin of the insertionSinceEnd of the insertion Begin of the deletion It has since beenEnd of the deletion confirmed Begin of the insertionreal,End of the insertion Begin of the deletion as realEnd of the deletion but not reachable from the UI Begin of the insertiontoday._End of the insertion Begin of the deletion today; see "Can a user hit this?" below._End of the deletion

## Context

Found while adding test coverage in #OP-19666 Begin of the deletion (custom-element morph policy consolidation)End of the deletion for a code path that had Begin of the insertionnoEnd of the insertion Begin of the deletion zeroEnd of the deletion prior tests. Pre-existing, not introduced by that work Begin of the insertion—End of the insertion Begin of the deletion -- confirmedEnd of the deletion the buggy `replaceWith` call is unchanged on `dev`.

## The bug

Begin of the insertionIn `DialogPreviewController`'sEnd of the insertion Begin of the deletion `frontend/src/stimulus/controllers/dynamic/work-packages/dialog/preview.controller.ts`, in `DialogPreviewController`'sEnd of the deletion `beforeNodeMorphed` callback Begin of the insertion(`frontend/src/stimulus/controllers/dynamic/work-packages/dialog/preview.controller.ts`, sharedEnd of the insertion Begin of the deletion (sharedEnd of the deletion by Begin of the insertionthe date-pickerEnd of the insertion Begin of the deletion `date-picker/preview.controller.ts`End of the deletion and Begin of the insertionprogress preview controllers):End of the insertion Begin of the deletion `progress/preview.controller.ts`):End of the deletion

```js
if (oldNode.tagName?.startsWith('OPCE-')) {
if (schedulingChanged) {
oldNode.replaceWith(newNode);
}
return false;
}
```

Begin of the insertion`replaceWith`End of the insertion Begin of the deletion `oldNode.replaceWith(newNode)`End of the deletion mutates both trees idiomorph is walking, Begin of the insertionbreakingEnd of the insertion Begin of the deletion and breaksEnd of the deletion the walk Begin of the deletion inEnd of the deletion two Begin of the insertionways:End of the insertion Begin of the deletion independent ways.End of the deletion

Begin of the insertion1. **StaleEnd of the insertion Begin of the deletion **1. StaleEnd of the deletion insertion point.** Begin of the deletion idiomorph'sEnd of the deletion `morphChildren` Begin of the deletion loopEnd of the deletion tracks its Begin of the deletion walkEnd of the deletion position via `insertionPoint = bestMatch.nextSibling`, evaluated Begin of the insertionafterEnd of the insertion Begin of the deletion _after_End of the deletion `morphNode` returns Begin of the insertion—End of the insertion Begin of the deletion --End of the deletion but `bestMatch` is the now-detached `oldNode`, so `nextSibling` is `null`. Remaining new children Begin of the insertionget appendedEnd of the insertion Begin of the deletion then fall through to `createNode(oldParent, newChild, null, ctx)`, which is `insertBefore(node, null)` -- an appendEnd of the deletion at the end of the Begin of the insertionparent, and theEnd of the insertion Begin of the deletion parent. TheEnd of the deletion trailing Begin of the insertion"removeEnd of the insertion Begin of the deletion "remove anyEnd of the deletion remaining old Begin of the insertionnodes"End of the insertion Begin of the deletion nodes"End of the deletion loop is guarded on the same `insertionPoint`, so stale old siblings Begin of the insertionsurvive.End of the insertion Begin of the deletion are never removed either.End of the deletion The result is duplication, not Begin of the insertionjustEnd of the insertion Begin of the deletion merelyEnd of the deletion staleness. Begin of the insertion

2. **SkippedEnd of the insertion Begin of the deletion

**2. SkippedEnd of the deletion new sibling.** `morphChildren` iterates Begin of the deletion `for (const newChild of newParent.childNodes)`. `childNodes` is a _live_ `NodeList` andEnd of the deletion the Begin of the insertionlive `newParent.childNodes` `NodeList` with an index-based iterator. MovingEnd of the insertion Begin of the deletion iterator is index-based. `replaceWith` movesEnd of the deletion `newNode` out Begin of the insertionshiftsEnd of the insertion Begin of the deletion of `newParent`, shiftingEnd of the deletion every later entry down one index, so the new sibling immediately Begin of the insertionafterEnd of the insertion Begin of the deletion followingEnd of the deletion the OPCE node is never Begin of the insertionvisited.


Net effect:End of the insertion Begin of the deletion visited at all.

**Net effect:**End of the deletion when `schedulingChanged` is true and an `OPCE-*` node is replaced, DOM siblings that follow it in the same parent are left stale, skipped, or duplicated.

Verified Begin of the deletion empiricallyEnd of the deletion with a standalone Begin of the deletion debugEnd of the deletion spec calling `Idiomorph.morph()` directly:

```text
BEFORE replaceWith, nextSibling: <div data-marker="old">old</div>
AFTER replaceWith, oldNode.nextSibling: null
AFTER replaceWith, oldNode.parentNode: null
FINAL HTML: <opce-test-marker data-marker="new"></opce-test-marker><div data-marker="old">old</div>
```

## Can a user hit this?

Begin of the insertionNo.End of the insertion Begin of the deletion No -- not in the current markup, and no UI reproduction exists.

End of the deletion The only `OPCE-*` element Begin of the insertioninEnd of the insertion Begin of the deletion insideEnd of the deletion any dialog served by `DialogPreviewController` is `opce-wp-date-picker-instance` Begin of the insertion(`app/components/work_packages/date_picker/form_component.html.erb`),End of the insertion Begin of the deletion (`app/components/work_packages/date_picker/form_component.html.erb`). It isEnd of the deletion emitted by Begin of the insertion`angular_component_tag` asEnd of the insertion Begin of the deletion `angular_component_tag`, which rendersEnd of the deletion a single empty Begin of the insertionelementEnd of the insertion Begin of the deletion element,End of the deletion and Begin of the insertionrendered asEnd of the insertion Begin of the deletion it isEnd of the deletion the sole child of its own `body.with_row` wrapper. With no siblings in that parent there is nothing for the broken walk to skip. Begin of the deletion

End of the deletion The Angular component Begin of the insertionadds noEnd of the insertion Begin of the deletion does not introduceEnd of the deletion siblings either: Begin of the insertionitEnd of the insertion Begin of the deletion `OpWpDatePickerInstanceComponent`End of the deletion renders its `<input>` inside the custom element host, and Begin of the insertionflatpickr&#x27;sEnd of the insertion Begin of the deletion flatpickr is configured withEnd of the deletion `inline: Begin of the insertiontrue` putsEnd of the insertion Begin of the deletion true`, soEnd of the deletion the calendar Begin of the insertionthere too.End of the insertion Begin of the deletion container is inserted next to that input -- still inside the host.

End of the deletion The progress dialog Begin of the insertionhasEnd of the insertion Begin of the deletion containsEnd of the deletion no `OPCE-*` elements and never sets Begin of the insertion`schedule_manually`.End of the insertion Begin of the deletion `schedule_manually`, so `schedulingChanged` is always false there.End of the deletion

Begin of the insertionSoEnd of the insertion Begin of the deletion That makesEnd of the deletion this Begin of the insertionisEnd of the insertion a latent Begin of the insertiontrap, notEnd of the insertion Begin of the deletion trap rather thanEnd of the deletion a live defect: adding a second element to that row, or flattening the `with_row` wrapper, would silently break the morph with no error and no failing test.

## Why it went unnoticed

No existing spec mounted a sibling alongside the OPCE node in the Begin of the insertion`schedulingChanged`\-replaceEnd of the insertion Begin of the deletion `schedulingChanged`-replaceEnd of the deletion case, so the gap was invisible until #OP-19666 added Begin of the insertioncoverage.End of the insertion Begin of the deletion coverage for it.End of the deletion

## Begin of the insertionHints for QAEnd of the insertion Begin of the deletion FixEnd of the deletion

Begin of the insertion**No UI reproduction existsEnd of the insertion Begin of the deletion https://github.com/opf/openproject/pull/24603

Replacements are collected during the walkEnd of the deletion and Begin of the insertionnoneEnd of the insertion Begin of the deletion applied once `Idiomorph.morph()` has returned. `oldNode` then stays attached for the whole walk, so the insertion point stays valid, and the queued nodeEnd of the deletion is Begin of the insertionexpected** — see &quot;Can a user hit this?&quot; above. There is nothing to test manually,End of the insertion Begin of the deletion `newNode.cloneNode(true)` rather than `newNode` itself,End of the deletion so Begin of the insertionthis can be closed directly afterEnd of the insertion the Begin of the insertionfixEnd of the insertion Begin of the deletion new tree idiomorphEnd of the deletion is Begin of the insertionmerged. CoverageEnd of the insertion Begin of the deletion iteratingEnd of the deletion is Begin of the deletion left untouched.

The narrowed spec from #OP-19666 (`date-picker/preview.controller.spec.ts`, "replaces an OPCE-* node when scheduling has changed") is un-narrowed, andEnd of the deletion a Begin of the insertionVitest regressionEnd of the insertion Begin of the deletion dedicatedEnd of the deletion case Begin of the insertionin `date-picker/preview.controller.spec.ts` that fails on `dev`End of the insertion Begin of the deletion now asserts the sibling morphsEnd of the deletion and Begin of the insertionpasses with the fix.End of the insertion Begin of the deletion is not duplicated.End of the deletion