fix(edit content): prevent duplicate content during drag-and-drop

[KevinDavilaDotCMS]

2026-08-11.18-34-49.mov

Changes Made

• Updated the to skip setting content while dragging, preventing potential duplicates.
• Introduced a new extension to handle drag-and-drop functionality for atom nodes, ensuring proper selection and movement.
• Added unit tests for the new extension to verify drag-and-drop behavior and atom node handling.

Testing

• Verified that dragging atom nodes does not create duplicates and that the editor behaves as expected during drag-and-drop operations.

This PR addresses issue #36976.

Proposed Changes

• change 1
• change 2

Checklist

• Tests
• Translations
• Security Implications Contemplated (add notes if applicable)

Additional Info

** any additional useful context or info **

Screenshots

Original	Updated
** original screenshot **	** updated screenshot **

[claude]

Claude finished @KevinDavilaDotCMS's task in 1m 54s —— View job

---

Code Review — PR #37031

• Read PR diff and changed files
• Analyze drag/drop fix logic
• Review test coverage
• Post review

---

This is a well-reasoned, well-documented fix. The approach — remove draggable: true from the atom node so it stops racing the gutter DragHandle, then guarantee the drop's source-delete by rewriting view.dragging to a real NodeSelection — is sound and matches how ProseMirror's move-drop actually works. The defensive layering (microtask patch on onElementDragStart + handleDrop fallback) is a nice touch.

New Issues

• 🟡 Medium: core-web/libs/new-block-editor/src/lib/editor/editor.component.ts:750 — writeValue now returns early during a drag but, unlike the !ed branch above it, does not buffer the dropped value into pendingValue. If Angular's CVA pushes a genuinely new value mid-drag (e.g. a patchValue/form reset while a block is being dragged), that value is silently discarded and never re-applied after the drag ends, since nothing re-triggers writeValue. The effect() path at line 620 is safe (it re-fires when this.value() changes), but the CVA path has no such recovery. Realistically rare — a form write during a drag gesture — so non-blocking, but worth a deliberate decision. Assumption: the parent may call writeValue independently of the [value] input. What to verify: whether any consumer patches the control mid-interaction. If keeping the guard, consider stashing into pendingValue and draining on onElementDragEnd. Fix this →

Notes (non-blocking)

• block-gutter.extension.ts:344 — patchAtomDragToNodeSelection correctly guards on nodeAt(pos) being an atom and view.dragging being present before creating the NodeSelection, so the microtask-vs-dragHandler ordering is handled safely. The handleDrop fallback (:482) only patches when moved && dragSourcePos >= 0 && node.isAtom && !dragging?.node, so cross-editor copies aren't affected. Logic looks correct.
• createFixDragImageOffsetHandler preview cleanup uses { once: true } on both dragend and drop; previewRoot.remove() is idempotent, so a double-fire is harmless.

Test coverage

Good. patchAtomDragToNodeSelection is covered for both the atom (rewrites to NodeSelection, sets selection) and non-atom (no-op) cases, and the contentlet spec adds a regression assertion that dotContent is not draggable at the node-spec level (the root cause of #36976). The full DOM drop flow isn't exercised, which is a reasonable limitation in jsdom.

---

No blocking issues. The Medium is an edge case worth a conscious decision before merge.
· 36976-block-editor-dragging-an-embedded-contentlet-to-reorder-duplicates-it-new-block-editor