[Beta]: Mention nodes can no longer be dragged in the Plate Playground

[felixfeng33]

Bug type

Regression (worked before, now fails)

Browser surface

Yes

Summary

Dragging the Alice mention in the Plate Playground creates a normal text selection instead of moving the mention.

Public reproduction URL

https://platejs.org/

Steps to reproduce

1. Open the Plate Playground on the current next/Beta lane.
2. Find the paragraph containing @mention users like Alice.
3. Press and drag the Alice mention horizontally across the surrounding text.
4. Release the pointer.

Expected behavior

The mention should be draggable and expose a drop position instead of selecting adjacent text. This matches the user-reported previous behavior and the repository's inline-mention drag/drop cursor coverage.

Actual behavior

The drag expands a normal blue text selection across the sentence. The Alice mention remains in place and no drop position is shown.

Acceptance criteria

• Dragging an inline mention moves it to the selected drop position.
• A visible drop cursor appears while dragging across valid inline positions.
• Dragging the mention does not create an ordinary text selection.

Plate / Slate / React versions

plate: NOT_ENOUGH_INFO
slate: NOT_ENOUGH_INFO
slate-react: NOT_ENOUGH_INFO
react: NOT_ENOUGH_INFO

Operating system

macOS (version NOT_ENOUGH_INFO)

Install method

Hosted Plate Playground

Framework / app setup

platejs.org Plate Playground

Affected packages or entry points

Plate Playground mention and drag-and-drop integration; exact package owner NOT_ENOUGH_INFO

Minimal code or config excerpt

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Recording timestamps:
[00:00–00:03] The pointer drags from the `Alice` mention across adjacent text.
[00:03–00:05] A normal text selection and floating toolbar appear; the mention does not move.
[00:05–00:07] The pointer returns to the mention, which remains in its original position.

Impact and severity

Affected: users editing inline mentions in the current Plate Beta Playground.
Severity: Medium; mention reordering by drag is blocked.
Frequency: one captured attempt; broader frequency is NOT_ENOUGH_INFO.
Consequence: users cannot reposition a mention with the expected drag interaction.

Additional information

CleanShot.2026-08-06.at.18.13.56.mp4

Regression range:

• last-known-good: NOT_ENOUGH_INFO
• first-known-bad: Plate next/Beta observed 2026-08-06
• evidence: attached 7-second recording

The recording is from Plate next/Beta testing. No console error is visible. Exact browser and build identifiers are NOT_ENOUGH_INFO.

Video evidence:

[dosubot]

This looks like an architectural gap rather than a recent regression. Here's what I found:

Root cause: Plate's DnD system is block-oriented. BlockDraggable only wraps elements at specific path depths (top-level blocks, columns, tables) [1]. Inline elements like mentions are invisible to this filter, so they never get Plate's drag-and-drop handling.

The mention component does set draggable: true and contentEditable: false on the DOM element [2], but there's no corresponding useDraggable integration. So when you try to drag, Slate's selection handling takes over and you get a text selection instead.

Recent changes ruled out:

• PR [codex] Fix discussion and suggestion regressions #4945 only added CSS classes to mention components — no DOM/drag attribute changes [3]
• PR fix(dnd): clear stale drop indicator in editor whitespace #5002 and fix(dnd): attach column drop target ref #5003 were block/column DnD fixes, not inline-related

To fix this, a few options:

1. Extend BlockDraggable to also handle inline void elements by checking editor.api.isInline(element) && editor.api.isVoid(element)
2. Create a dedicated InlineDraggable wrapper that uses useDraggable with inline-specific drop logic and register it with mentions
3. If inline drag isn't needed, remove draggable: true from the mention component to avoid the confusing selection behavior

The DnD hooks (useDraggable, useDndNode) are generic enough to support inline elements [4], but the UI layer (BlockDraggable) and the kit config (DndKit) don't wire them up for inline voids [5].

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[zbeyens]

Fixed locally; there is no commit or PR yet.

The mention drag path now uses a real pointer gate for inline voids, computes the text target from the actual string range, and moves the internal slice atomically with a stable anchor. Mention HTML serialization also preserves the element identity required by the drop path.

Proof:

• focused Chromium mention drag-and-drop scenario passed 3 consecutive runs
• 30 focused unit tests passed
• affected package typechecks passed
• targeted Biome checks passed
• P2 autoreview found no actionable issues

I added a patch changeset. Leaving this issue open because the fix is local only.

[felixfeng33]

Follow-up manual retest: dragging the Alice mention shows a caret, but the mention does not move. Keeping this open.

[zbeyens]

Local candidate repaired on base 1fb72c5810; it is uncommitted and unpushed, with no PR yet.

The durable fix has two owners: block DnD no longer claims every keyed Plite native drag, and Plite fitted slice replacement now composes through a detached transaction spec so inline delete-and-reinsert moves publish atomically without weakening schema validation.

Proof on the current dirty source:

• exact Playground Alice drag: 5/5 Chromium runs, zero retries; Alice moves past or insert, the drop caret appears, and native selection stays empty
• existing Playground block drag plus follow-up editing: passed
• DnD contract: 5 passed; Plite slice-fit contract: 49 passed; Plite React native bridge: 18 passed
• DnD, Plite, and Plite React package typechecks passed

The issue stays open and the completed label stays off until the same case passes on the final pushed ref.

[felixfeng33]

Confirmed on the current pushed next ref ea82e578400db911a882f7f6b1d685a2059af22f.

The reporter's latest retest removed this row. Fresh exact Chromium replay of dragging the Alice mention passed 5/5: the mention moved to the target, native text selection stayed empty, follow-up editing worked, and no runtime or page errors occurred.

Closing as fixed on next; this is not a stable-release claim.