[Beta]: Drag-selecting from one root into another in the Multi-root Document example throws "Cannot resolve view-boundary point"

Start with packages/plitejs/src/react/view-boundary-graph-core.ts, where requirePointNode, comparePoints and segmentRange appear in the reported error path. Trace how mouse moves in the multi-root document example reach segmentRange and how points from another root are handled. Reproduce a drag between the Body and Footer editors, then verify it no longer throws and the selection remains in the starting root.

Testing lane

• Repository: udecode/plate
• Branch: next
• Release channel: Beta
• Exact commit/package version: NOT_ENOUGH_INFO

Summary

On /examples/plite/multi-root-document, a mouse drag that starts in one editor and moves into another throws an uncaught error while the pointer moves: Cannot resolve view-boundary point in root "<root>" with owner "none" at path <path>. The error shows only in the console. On the page, the selection stays in the editor where the drag started. A drag that stays inside one editor throws nothing.

Reproduction

The page shows three editors under the Document title field: Header editor, Body editor and Footer editor. Each one is a separate root of the same document.

Repro 1: /examples/plite/multi-root-document, Chromium-based browser

natamox ran this by hand.

1. Open https://beta.platejs.org/examples/plite/multi-root-document and open the DevTools console.
2. In the Body editor, press the mouse just before roots. in the second line, Header and footer are editable roots..
3. Keep the button down and drag onto the Footer editor text, Prepared for leadership review.

When the pointer reaches the Footer editor, the console logs Uncaught Error: Cannot resolve view-boundary point in root "footer" with owner "none" at path 0.0., and keeps logging it while the pointer moves over the footer text. The page still highlights only roots. in the Body editor.

Repro 2: /examples/plite/multi-root-document, Chromium

An agent ran this with Playwright.

1. Open https://beta.platejs.org/examples/plite/multi-root-document.
2. Control: in the Body editor, press after Header and and drag to editable in the same line.
3. Click the same spot once to clear the selection. Then press there, drag down onto the Footer editor text, and release.
4. Press in the Footer editor text and drag up onto the Body editor text.
5. Press in the Header editor text and drag down onto the Body editor text.
6. Type X.

Step 2 throws nothing. Steps 3, 4 and 5 each throw while the pointer moves: root "footer" at path 0.0 in step 3, and root "main", the Body editor, at path 1.0 in step 4 and 0.0 in step 5. The selection on the page stays in the root where each drag started: footer are editable roots. in the Body editor, Prepared in the Footer editor and ential quarterly plan in the Header editor. In step 6, X replaces the highlighted text, so the Header editor reads ConfidX. The other editors keep their text, and no new error is thrown.

A press on text that is already selected starts a text drag instead, which is why step 3 clears the selection first. Each drag has to end on another editor's text, not on the gap between two editors.

Expected

The page has no Slate reference, because slatejs.org has no multi-root example. As the tester (natamox) expects: dragging a selection never throws, and the selection stays in the root where the drag started, as the page already shows. A drag inside one root, step 2 of repro 2, already behaves this way.

Actual

Each drag that moves into another root throws Uncaught Error: Cannot resolve view-boundary point in root "<root>" with owner "none" at path <path>., where <root> is the root under the pointer. The recordings show footer and main, and the agent's notes record header for a drag that moves into the Header editor. Headless Chromium threw about 4 to 30 errors per drag, more for a longer drag. Playwright WebKit threw one per drag. Nothing on the page shows the error.

The console stack in repro 1 lists comparePoints and segmentRange, and most entries also list onMouseMoveCapture.

Environment

• Exact next commit/Beta package version: NOT_ENOUGH_INFO. The agent's runs used Beta built from next 7f2eacb6eb and, after Beta was redeployed at 08:56 PT, from next 0500826291, with the same result. Neither recording names its build.
• On 2026-10-24 an agent replayed repro 2 on the live Beta in headless Chromium 149 and Playwright WebKit 26.5, and both still throw.
• Repro 1: natamox by hand on 2026-10-22 (PT). The browser is Chromium-based: the console in the recording is Chrome DevTools, and its stack lines use the at name (file:line) form. The recording does not show which browser it is or its version. The DevTools hint shows the cmd key, which points to a Mac.
• Repro 2: an agent on 2026-10-22 (PT), at natamox's request, in headless Chromium 149.0.7827.55 on macOS, driven by Playwright with real mouse and key input. The same steps in Playwright WebKit 26.5 (not Safari) also threw. The agent reproduced it in a desktop Chromium 152 window as well.
• Nobody has tried Safari itself, Firefox or a phone.

Caveat

• From a reading of the code on next, which finds where the error is thrown and does not trace the caller: the message comes from requirePointNode (packages/plitejs/src/react/view-boundary-graph-core.ts:293, thrown at :304) when the graph it is given has no node for the point. segmentRange (:384) reaches it through comparePoints, which matches the console stack. Which caller passes segmentRange a point in another root on a mouse move is not traced.
• An inference from the agent's notes, not checked: on a mouse move, Plite maps the point under the pointer into that other root and builds a range from it and the drag's start, but the graph it uses has no nodes for the other root. The browser keeps the native drag selection inside the editor where it started, which would be why the page shows nothing wrong.

Evidence

• Repro 1: natamox's screen recording, 6.5 seconds, with the page on the left and the DevTools console on the right. At 0:00 the caret is at the end of roots. in the Body editor, and the console is empty. From 0:01 the pointer moves to just before roots., and at 0:03 the drag highlights roots. and moves down. At 0:03.7 the pointer reaches the Footer editor, and the first error appears. From 0:04 to the end, the console fills with the same error while the page still highlights only roots..
• Repro 2: headless Chromium recording, 42 seconds, with an English step panel. A readout box drawn by the test script shows the uncaught page errors so far, the mouse button and the selection on the page, and a red box at the top, also drawn by the script, shows the last error. From 0:01 the control drag in the Body editor selects footer are editab, and the count stays 0. From 0:08 the drag into the Footer editor runs, and by 0:11 the count is 10, with root "footer". From 0:14.5 the drag up from the Footer editor runs, and by 0:17.5 the count is 38, with root "main". From 0:21 the drag down from the Header editor runs, and by 0:24 the count is 51. At 0:28 X replaces the highlighted Header editor text, and the count stays 51. The result shows from 0:31.5 to the end.

Repro 1 — Chromium-based browser, /examples/plite/multi-root-document

https://github.com/user-attachments/assets/15373536-be52-46e6-a3e4-caa28865a1c1

Repro 2 — headless Chromium, /examples/plite/multi-root-document

https://github.com/user-attachments/assets/45f11434-8094-4904-a021-5e71fb9d8705