[Beta]: In the Synced Blocks example, Shift+↑ after a click and Backspace miss the synced block, and typing over a whole block hides the text

Start with packages/plitejs/src/react/editable/selection-controller.ts and content-root-navigation.ts to trace Shift+↑ after a click, then inspect packages/plitejs/src/core/editor-commands.ts for whole-block deletion. Read apps/plite/tests/plite-browser/donor/examples/synced-blocks.test.ts and add browser cases for keyboard selection and replacement in the synced-blocks example. Done when both reported repros behave as expected; the behavior for deleting a whole synced copy still needs a decision.

Testing lane

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

Summary

On /examples/plite/synced-blocks, keys act on the wrong place when a selection reaches into a synced block from the line below it, or covers a whole synced block.

• Shift+↑ does nothing right after a click at the start of the line below a synced block. After an arrow key it highlights the block's last line, but Backspace then deletes nothing.
• Typing over a selection that covers a whole synced block deletes the paragraph above and empties every copy of the block. The typed text does not show on the page.

Reproduction

Repro 1: /examples/plite/synced-blocks, Chromium

From the top, the page shows p1 and then a synced block whose header reads Editing original, with the lines Shared mission statement and Editing any copy updates every synced copy.. Below it are Between synced copies., a second synced block, Between synced documents., a third block that is a copy of the first, and p2.

1. Open https://beta.platejs.org/examples/plite/synced-blocks.
2. Click the start of Between synced copies..
3. Press Shift+↑.
4. Press → and then ←. The caret is back at the start of the line.
5. Press Shift+↑ again.
6. Press Backspace.
7. Control: click the start of Between synced copies. again, press → and ←, press Shift+↑, and type X.

Step 3 changes nothing. No highlight appears, and the model selection does not move. Step 5 highlights Editing any copy updates every synced copy.. Step 6 deletes nothing. The highlight goes away, and the caret moves to the end of Editing any copy updates every synced copy.. In step 7, X replaces the highlighted line and the line break before it, so the block reads Shared mission statementX, although the highlight did not show the line break as selected.

Shift+↑ right after a click at the start of p2 or Between synced documents. also does nothing. After a click at the start of a line inside a synced block, it works. After the click alone and after → and ←, the browser's selection and the model selection are both at the start of Between synced copies., yet only the second lets Shift+↑ work.

Repro 2: /examples/plite/synced-blocks, Chromium

1. Open https://beta.platejs.org/examples/plite/synced-blocks.
2. Click the start of Between synced copies., then press → and ←, because of repro 1.
3. Press Shift+↑ three times. The highlight covers p1 and both lines of the first synced block.
4. Type X.
5. Type Y.
6. Press ⌘Z.
7. Press ⌘Z again.

In step 4, p1 disappears, and both copies of the shared block show Empty synced block. X does not show on the page. The test script's readout shows it in the synced block's own text, which the page never renders. In step 5, Y goes there too, so that text is XY. Step 6 removes only Y, and the block stays empty. Step 7 restores everything.

In WebKit 26.5, Y is dropped and that text stays X, and one ⌘Z restores everything. Starting at the start of p1, Shift+↓ three times and Backspace also empty the synced block.

Expected

• Repro 1: Shift+↑ right after the click extends the selection into the synced block, as it does after an arrow key and from the start of a line inside the block. The plan for this example on next, docs/plans/2026-05-27-synced-blocks-sibling-selection.md, asks that synced blocks select like ordinary adjacent paragraphs with Shift and the arrow keys. Backspace deletes the highlighted text, as typing X replaces it in step 7.
• Repro 2: The typed text shows on the page where it was typed.

Actual

• Repro 1: Shift+↑ after a click does nothing. Backspace over a selection that reaches into the synced block deletes nothing.
• Repro 2: Typing deletes the paragraph above and the shared text of every copy, and the typed text goes where the page does not show it.

Environment

• Exact next commit/Beta package version: NOT_ENOUGH_INFO
• Both repros: an agent in headless Chromium 149.0.7827.55 and Playwright WebKit 26.5 (not Safari) driven by Playwright with real key and mouse input, 2026-10-22 (PT). The recordings use Chromium on macOS. natamox confirmed both by hand in Chrome the same day.
• On 2026-10-24 an agent replayed both on the live Beta in headless Chromium 149, and both still fail.
• No agent run used Firefox or Safari itself. Nobody has tried them on a phone or with an input method.

Caveat

• Repro 1 has a reading of the code on next, not confirmed. From packages/plitejs/src/react/editable/selection-controller.ts:361 on, the keyboard layer tells a selection taken from the browser apart from one the model owns (selectionSource === 'model-owned'). It looks like a mouse click leaves the first kind and an arrow key the second, and Shift+↑ into the synced block is handled only for the second. shouldModelOwnContentRootVerticalSelection returns early for a collapsed selection (packages/plitejs/src/react/editable/content-root-navigation.ts:1281), so a caret takes another path. Backspace gives the same result as Backspace with a plain caret at that spot, which suggests the delete reads a different selection than typing does.
• For repro 2, the schema gives the synced block element text of its own (apps/www/src/app/(app)/examples/plite/_examples/synced-blocks.tsx:111, schema.content.text({ default: 'text', min: 1 })), and the example does not render that text. That is read from the code. An inference, not traced: after the delete removes p1 and the shared text, the caret and the typed text land in that hidden text. The whole-block delete branch in packages/plitejs/src/core/editor-commands.ts:620 may be involved, which is also an inference.
• What should happen when a selection covers one whole synced copy, such as removing that copy or keeping the shared text, is not decided here.
• From an agent's reading of apps/plite/tests/plite-browser/donor/examples/synced-blocks.test.ts, its Shift+↑ and Backspace cases set the selection by script. A selection made with the keyboard after a click, one made upward and one covering a whole block are not tested.

Evidence

• Repro 1: headless Chromium recording, 34 seconds, with an English step panel and a readout box drawn by the test script. The readout lists the blocks, the shared text, each synced block's own hidden text, the model selection, the highlighted text and focus. At 0:03 the click puts the caret at the start of Between synced copies.. At 0:05 Shift+↑ changes nothing. At 0:08 → and ← are pressed, and at 0:11 Shift+↑ highlights Editing any copy updates every synced copy.. At 0:14 Backspace removes the highlight and deletes nothing, and the caret moves to the end of that line. The control run starts at 0:18, and at 0:20 X makes the block read Shared mission statementX. The result holds from 0:23.
• Repro 2: headless Chromium recording, 33 seconds, in the same layout. From 0:05 Shift+↑ is pressed three times, and by 0:06 the highlight covers p1 and both lines of the first synced block. At 0:10 X is typed. p1 is gone, the first block shows Empty synced block, and the readout shows X in the block's own hidden text and the third block empty too. At 0:13 Y changes nothing on the page, and the readout shows XY. At 0:16 ⌘Z removes only Y, and at 0:19 the second ⌘Z restores everything. The result holds from 0:23.

Repro 1 — headless Chromium, /examples/plite/synced-blocks

https://github.com/user-attachments/assets/b5eff9ff-4a98-4fc9-aa3e-948d72610404

Repro 2 — headless Chromium, /examples/plite/synced-blocks

https://github.com/user-attachments/assets/655059f5-3dbf-4f5b-ad5f-a0fd97562d9c