[Beta]: With two views of one editor, the Undo and Redo buttons do nothing and clicking past a line's end does not focus the editor

Start with packages/plitejs/src/react/hooks/use-plite-history.ts and trace applyHistory into packages/plitejs/src/react/editable/editable-dom-runtime.ts and packages/plitejs/src/dom/plugin/dom-root-runtime.ts. Then inspect apps/plite/tests/plite-browser/donor/examples/external-text.test.ts and reproduce both cases in the external-text example. Done means clicks after a line’s end focus the clicked view, and Undo/Redo buttons update the shared history as keyboard shortcuts do.

Testing lane

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

Summary

The example at /examples/plite/external-text shows one Plite document in two views. Native Plite is on the left. External text view is on the right, and its middle block is a plain textarea. Both views share one undo history. On this page:

• Clicking the blank space after a line's end moves the editor's selection to the end of that line, but keyboard focus does not move. The next typed character is lost, or goes into the textarea when the textarea had focus. Clicking on the text itself works.
• The Undo and Redo buttons below Native Plite do nothing. ⌘Z and ⌘⇧Z work.

Both are small. This issue covers both because a reading of the code points to one cause.

Reproduction

Repro 1: /examples/plite/external-text, Chromium

1. Open https://beta.platejs.org/examples/plite/external-text in a fresh tab.
2. In Native Plite, click the blank space to the right of the first line, Before the external view.
3. Type Z.
4. In External text view, click the blank space to the right of the same line, and type Z.
5. For comparison, click on the word view. in the first line of Native Plite, and type Z.
6. Click the end of the textarea text and type abc.
7. Click the blank space to the right of the first line in Native Plite again, and type Z.

After steps 2 and 4 the editor's selection is at the end of the first line, but keyboard focus stays on the page body, and neither Z appears. In step 5 the Z appears after view. in both views. In step 7 focus stays in the textarea, and the Z goes to the end of the textarea, after abc, not to the first line. A click 2 px or 60 px to the right of the line end gives the same result. WebKit does the same.

Repro 2: /examples/plite/external-text, Chromium

1. Open https://beta.platejs.org/examples/plite/external-text in a fresh tab.
2. Click the end of the textarea text and type abc.
3. Click Undo, below Native Plite. Click it again.
4. Click on the word view. in the first line of Native Plite, and type xyz.
5. Click Undo.
6. For comparison, click the end of the textarea text and press ⌘Z twice.
7. Click Redo.
8. For comparison, click the textarea and press ⌘⇧Z.

Steps 3 and 5 change nothing, and Undo stays enabled. In step 6 the two ⌘Z presses remove xyz and then abc, and Redo becomes enabled. Step 7 changes nothing. In step 8 ⌘⇧Z brings abc back. In WebKit the buttons do nothing either, and focus is on the page body after the click.

Expected

• A click in the blank space after a line's end puts the caret at the end of that line and focuses the view that was clicked, the same as a click on the text. The agent's run recorded that the Rich Text and Plain Text examples (/examples/plite/richtext and /examples/plite/plaintext) on Beta do this.
• The Undo and Redo buttons undo and redo the latest change from either view, as ⌘Z and ⌘⇧Z do on the same page. The document itself reads Undo is shared.

Actual

• The click moves the editor's selection to the line end, but focus stays where it was. On a fresh page that is the page body. After the textarea was used, it is the textarea. Typed text is lost or goes into the textarea.
• Clicking an enabled Undo or Redo button changes nothing and shows no error. The button stays enabled.

Environment

• Exact next commit/Beta package version: NOT_ENOUGH_INFO
• An agent ran both repros on 2026-10-22 (PT) with Playwright 1.61, using real mouse and keyboard input, in headless Chromium 149.0.7827.55 and in Playwright WebKit 26.5 (not Safari) on macOS. Both engines reproduce both bugs. The recordings use Chromium.
• natamox retested the page by hand on 2026-10-22 (PT), confirmed both bugs, and rated them minor. The browser of that retest was not recorded.
• Not tested: Safari, Firefox, mobile, and real input methods.

Caveat

• This is a reading of the code on next at bb6147452c, not confirmed with a breakpoint or a fix. The buttons call applyHistory in useEditorHistory (packages/plitejs/src/react/hooks/use-plite-history.ts:153). It looks up the view through getMountedEditableDOMRuntime (packages/plitejs/src/react/editable/editable-dom-runtime.ts:233). pickView (packages/plitejs/src/dom/plugin/dom-root-runtime.ts:333) uses the only view when there is one, and otherwise only the view that contains focus. After a button click, focus is on the button in Chromium or on the page body in WebKit, so the lookup finds no view and the call does nothing. ⌘Z works because its key event finds the view from the event target.
• For the click, an agent's probe saw that the mousedown landed on the paragraph element, not on its text, and that the editor handled it itself and set the selection to the line end, so the browser did not move focus. The focus call that should follow goes through the same view lookup. On a fresh page no view has focus, so nothing is focused. When the textarea has focus, the lookup finds the right view, and focus stays in the textarea. This part is an inference. Nobody traced it line by line.
• By the same reading, pages with one view of the editor are not affected.
• apps/plite/tests/plite-browser/donor/examples/external-text.test.ts covers keyboard undo and the test harness's undo, but never clicks the two buttons.

Evidence

• Repro 1: headless Chromium recording, 39 seconds. The real page is on the left and an English step panel on the right. The dark box at the bottom of the page is drawn by the test script and is not part of the page. It shows which element has keyboard focus, the editor's model selection as block,text@offset, the focus moves, the keys pressed and whether the buttons are enabled. An orange ring marks each click. By 0:02 the click after the first line in Native Plite has moved the selection to 0,0@25 while focus stays on the page body, and the Z typed at 0:04 does not appear. After the click in External text view, the Z typed at 0:11 does not appear either. By 0:14 a click on view. has focused Native Plite, and by 0:15 Z shows in both views. At 0:22 the click after the first line in Native Plite leaves focus in the textarea, and by 0:25 the Z has gone into the textarea after abc.
• Repro 2: headless Chromium recording, 42 seconds, in the same layout. At 0:06 and 0:09 the script clicks Undo, and abc stays. At 0:16 it clicks Undo after typing xyz in Native Plite, and nothing changes. By 0:20 the first ⌘Z has removed xyz, and by 0:21 the second has removed abc and Redo is enabled. At 0:25 it clicks Redo, and nothing changes. By 0:28 ⌘⇧Z has brought abc back. From 0:21 the page's Outer input events counter reads 2. The first ⌘Z moved focus from the textarea to the right editor along with the restored selection, so the second ⌘Z went through that editor. The tester did not count this as a bug.

Repro 1 — Chromium, /examples/plite/external-text

https://github.com/user-attachments/assets/ef866763-d71a-4d9b-8750-ba6b767e9a61

Repro 2 — Chromium, /examples/plite/external-text

https://github.com/user-attachments/assets/553c4765-4d87-451e-a58a-afc23bf4e9c1