[Bug] Table: clicks on unmapped DOM regions desync selection and crash toSlateRange on typing/paste

[caspersf]

Description

When a note-style editor contains one or more tables, clicking inside the editor on a DOM region that has no data-slate-node ancestor (the contentEditable's own padding, the gap between two adjacent tables, or below the last table if no trailing paragraph exists) leaves editor.selection stale while DOM selection drifts to the unmapped wrapper. Subsequent typing or pasting then crashes inside slate-react:

Uncaught Error: Cannot resolve a Slate point from DOM point: [object HTMLDivElement],2
at Object.toSlatePoint (index.es.js)
at Object.toSlateRange (index.es.js)
at HTMLDivElement. (index.es.js)

Related symptoms from the same root cause:

• Type after clicking outside the table → text lands in the last cell the caret was in (stale editor.selection), not where the click was.
• Repeat a few times → text is sometimes inserted natively into the unmapped DOM region, diverging DOM from the Slate model → next interaction crashes with the error above.
• Paste after clicking outside the table → immediate crash (only when clipboard carries editor-originated Slate/HTML; plain text from outside the editor typically escapes this path).

This is reproducible in the official Plate demo at https://platejs.org/docs/table — the error is thrown to the console there too, but the demo has no top-level error boundary so the page doesn't visibly crash. Apps that register a window.error handler or an ErrorBoundary-style unmount-on-error will crash.

My integration registers only the table plugins (TablePlugin, TableRowPlugin, TableCellPlugin) alongside basic marks, paragraph, font, indent, list, and docx/juice paste plugins. I do not install TrailingBlockPlugin, DndPlugin / DndKit, BlockSelectionPlugin, CursorOverlayPlugin, NodeIdPlugin, or any related helper plugin. The docs demo does install these, which seems to mask some of the click-landing problems by providing additional mapped click surfaces — but the underlying throw from toSlateRange still fires there.

Expected behavior

Clicks inside the editor should always produce a valid editor.selection, either by ensuring a clickable Slate-mapped region exists for every reachable pixel (e.g., a trailing paragraph after the last table + inter-table paragraph normalization in the table plugin), or by toSlateRange never throwing on user-interaction paths (returning null and falling through).

Nice-to-have: when a click lands outside any table (in an unmapped region of the editor), the selection could be snapped to the last cell of the nearest table — the same behavior that already happens when only a single table is present. With a single table, clicking below/outside the table keeps focus in the table's last cell; with multiple tables, that fallback is lost and focus/selection disappears entirely.

The current behavior is that a single stray click inside the editor can put the editor in an unrecoverable state.

Reproduction URL

https://platejs.org/docs/table

Reproduction steps

On https://platejs.org/docs/table (or any editor built from the docs demo with TableKit):

1. Insert two tables (or one table followed by no trailing paragraph).

2. Put the caret in a cell and type a few characters.

3. Click in the gap between the two tables (or just below the last table). Note the caret disappears visually — editor.selection did not update because the click target has no data-slate-node ancestor.

4. Type text. The text is inserted into the last cell (where the caret was) rather than where you clicked, because editor.selection is stale.

5. Click outside again, type again. Repeat.

6. After a few iterations, native contentEditable insertion ends up in the unmapped DOM region (visible text appears below the table with no Slate block backing it), and the next interaction throws:

   Error: Cannot resolve a Slate point from DOM point: [object HTMLDivElement],<offset>

Variant (paste-only, no repeated typing needed):

3a. After step 3 above, press Ctrl+V with anything rich in the clipboard (e.g. a previously copied paragraph or cell from within the editor).

Observed: immediate throw of the same error.

Plate version

52.0.17 (platejs), 52.0.11 (@platejs/table)

Slate React version

0.120.0

Screenshots

The ccsc text below the first table, is invalid text that is rendered below the table, post the error

Logs

Uncaught Error: Cannot resolve a Slate point from DOM point: [object HTMLDivElement],2
at Object.toSlatePoint (index.es.js)
at Object.toSlateRange (index.es.js)
at HTMLDivElement. (index.es.js)

Browsers

Chromium (Chrome/Edge) on Linux and macOS

[dosubot[bot]]

Hi @caspersf! I'm Dosu and I’m helping the plate team.

Good bug report. This is a real issue — here's what I found digging into the code:

Root cause: In the Slate fork's onDOMBeforeInput handler, there are two toSlateRange calls that use suppressThrow: false [1] [2]. When a click lands on an unmapped DOM region (no data-slate-node ancestor), the DOM selection drifts but editor.selection stays stale. The next typing or paste event hits one of these toSlateRange calls, which throws instead of returning null.

Plate does have a wrapper around toSlateRange that silently catches errors [3], but these event handlers in slate-react call ReactEditor.toSlateRange directly — bypassing that wrapper entirely.

Why TrailingBlockPlugin masks it: Without TrailingBlockPlugin, there's no trailing paragraph after the last table, so there's no Slate-mapped DOM region below it. Clicks in that area hit the raw contentEditable div. With the plugin enabled, the trailing paragraph provides a valid click target, reducing (but not eliminating) the issue.

Two things that could fix this:

1. Slate-react level: The two unsafe toSlateRange calls in onDOMBeforeInput (lines ~561 and ~685) should either use suppressThrow: true or be wrapped in try/catch, consistent with the other 5 calls in the same file that already use suppressThrow: true [4].

2. Table plugin level: The table plugin's withNormalizeTable [5] could normalize the document to ensure a mapped block exists between adjacent tables and after the last table — similar to what TrailingBlockPlugin does globally, but scoped to table boundaries.

For now, adding TrailingBlockPlugin to your setup is the quickest workaround to reduce the frequency of this crash.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[caspersf]

Even with TrailingBlockPlugin or a block between tables, clicking in the padding region of the editor, takes focus away from the table, and causes this issue. Suppressing the error is also not a workaround, since it causes text to render outside the intended position(typing in table, renders texts outside it), and not part of the Plate Value structure.

[caspersf]

@zbeyens if you could check this out please.

[zbeyens]

Please convert this into an issue. I'll take a look later.