docs/solutions/logic-errors/2026-04-12-firefox-drag-drop-proof-needs-example-owned-drop-mutation-and-document-level-drag-cleanup.md
The first Firefox drag/drop row looked green on paper and red in reality.
We added generic drag handlers to Editable and a new drag-drop-cleanup
example, then tried to reorder void cards with a plain Playwright dragTo.
The first attempt crashed during dragstart.
After that fix, the crash disappeared, but the order still never changed.
That split the problem into two different truths:
Editable matteredWithout the second part, the test was poking browser drag events but not proving the legacy Firefox case we cared about.
Two changes made the row honest:
Editable stopped routing dragstart back through findPath(node) and
resolved the dragged path from the DOM node directly.onDragStart wrote a card id into dataTransferonDragOver allowed drop on the explicit zone paragraphsonDrop replaced the top-level editor children to reorder the cards and
called preventDefault()That last detail is the point of the row.
When the example short-circuits the internal drop handler, the document-level
dragend / drop cleanup in Editable still has to clear internal drag
state after the dragged node unmounts.
The proof is the second drag:
Legacy Slate carried the global Firefox drag cleanup for a reason.
Dragged nodes can disappear before their own local dragend path finishes.
If the current proof row only checks one drag, it can miss the dirty internal drag state that breaks the next interaction.
For Firefox drag/drop parity rows:
dragend / drop cleanup active