[Beta]: On Android Chrome, paste inserts the copied text twice, and later typing lands between the copies or elsewhere

Start by reading packages/plitejs/src/react/editable/clipboard-input-strategy.ts around applyEditablePaste and packages/plitejs/src/react/hooks/android-input-manager/android-input-manager.ts around the insertFromPaste branch. Compare how the paste and beforeinput events are handled on Android, then check the existing tests for these paths. Done means Android Chrome inserts copied text once, leaves the caret after it, and subsequent taps place the caret correctly.

Testing lane

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

Summary

On Android Chrome, Paste from the long-press menu inserts the copied text twice on Beta. The caret then sits between the two copies, so the next typed letter goes there. After a tap outside the editor and a tap back at the end of the text, the caret can also land somewhere else in the paragraph. Nine Beta examples show it. Five of them have a Slate counterpart, and on slatejs.org the same steps paste the text once in all five.

Reproduction

Repro 1: /examples/plite/plaintext, Android Chrome

1. Open https://beta.platejs.org/examples/plite/plaintext.
2. Tap the end of the text and type alpha beta. The recorded run then pressed Delete, pressed Enter, typed gamma, pressed Delete six times to remove gamma and the line break, and committed 你好 with pinyin nihao. The text now ends alpha bet你好.
3. Long-press alpha and tap 复制 (Copy).
4. Tap the end of the text.
5. Long-press the end of the text and tap 粘贴 (Paste).
6. Tap outside the editor. In the recorded run the tap lands on the page heading.
7. Tap the end of the text again and type z.

After step 5 the text ends alpha bet你好alphaalpha, with the caret between the two copies. In step 7 the caret lands after This at the start of the paragraph, and z goes there: This zis editable plain text. On https://www.slatejs.org/examples/plaintext the same steps paste alpha once, and z lands at the end: alpha bet你好alphaz.

Repro 2: /examples/plite/comment-mode, Android Chrome

The Edit mode panel is the editor whose header reads Edit mode and document writes enabled.

1. Open https://beta.platejs.org/examples/plite/comment-mode.
2. In the Edit mode panel, long-press anchored in the first paragraph and tap 复制 (Copy).
3. Tap the end of the second paragraph, after sync..
4. Long-press the same spot and tap 粘贴 (Paste).
5. Type z.
6. Tap outside the editor, then tap Clear comments.

After step 4 the second paragraph ends sync.anchoredanchored, with the caret between the copies. z lands there: sync.anchoredzanchored. The comment's range does not move. After step 6 the paragraph ends sync.anchoredz, and the copy after z is gone. In the recording it is already gone when the page has scrolled down to the buttons and the comment card is still on screen, before Clear comments removes the comment.

The recorded run did nine other steps on the page first. It seeded, retoned and updated a comment, and typed and deleted 你好 and a line break in Edit mode. slatejs.org has no matching example.

Other examples, Android Chrome

The same paste went in twice on seven more examples, in runs on the same phone on the same day. Each copied a word with a long press and Copy, tapped the end of the text, long-pressed it and tapped Paste. Where the table says so, the run then tapped outside the editor and back at the end before typing z.

On /examples/plite/schema-reconfiguration, a tap inside the primary root's guard before the long press makes Paste crash the page instead. That is #5243. Without the tap, the paste only goes in twice.

Expected

Paste inserts the copied text once and leaves the caret after it, as on slatejs.org. A later tap at the end of the text puts the caret at the end.

Actual

Paste inserts two copies, and the caret sits between them, so the next letter goes there. After a tap outside and back, the caret can land elsewhere in the paragraph, such as after This in repro 1.

Environment

• Exact next commit/Beta package version: NOT_ENOUGH_INFO
• Device: Xiaomi 14, Android 16, Chrome 154, WeType pinyin keyboard in its 9-key layout. An agent ran every repro and every example in the table on natamox's real phone on 2026-10-23 (PT), with slatejs.org as the reference where Slate has the same example. These are agent runs, not tests by hand, and nobody has retested them by hand.
• Nobody has tried these steps on iPhone or iOS Safari.
• An agent's desktop Chrome run on /examples/plite/plaintext on 2026-10-21 copied and pasted two once.

Caveat

• From a reading of the code on next, which traces the path and does not prove the cause: applyEditablePaste handles the paste event (packages/plitejs/src/react/editable/clipboard-input-strategy.ts:980). When the browser supports beforeinput and the clipboard holds more than plain text, it leaves the paste to beforeinput (the condition at :1046). On Android, insertFromPaste reaches packages/plitejs/src/react/hooks/android-input-manager/android-input-manager.ts:995. That branch schedules an insert-data command and returns without cancelling the event.
• An inference from that reading, not checked with a change: Chrome also inserts the text into the page, so the page shows two copies while the document holds one. A tap is then mapped to a document position through text the document does not have, which would put the caret in the wrong place. An agent's event log on /examples/plite/huge-document recorded a paste event and then a beforeinput with insertFromPaste for the same paste.
• Repro 2 fits that inference. The copy after z went away after the editor lost focus, which suggests it was only on the page and never in the document. Nobody checked the document data. The recording does not show whether the copy went when the page scrolled or when Clear comments was tapped.
• Every recorded run typed in the editor before it copied, and each copy came from the same page. Pasting text copied from another app was not tested.
• In the repro 1 recording, the tap in step 4 shows a caret without a drag handle on Beta, while Slate shows one. That is #5247 and not part of this issue.

Evidence

• Repro 1: screen recording from the phone, 26 seconds, cut from a longer run, with an English step panel beside it. The keyboard's suggestion row is blurred, and a note covers the panel's first eight steps. At 0:00 the long press selects alpha. From 0:12 the long press at the end of the text shows the paste menu. At 0:17 Paste puts in alphaalpha, with the caret between the two copies. At 0:18 the tap outside the editor lands on the page heading, and Chrome's search sheet for Plain opens at the bottom. At 0:20 the tap at the end of the text puts the caret after This , and at 0:21 z appears there.
• Repro 1 reference: slatejs.org with the same steps, 25 seconds, in the same layout. At 0:17 Paste puts in one alpha. At 0:21 z lands at the end, after alpha.
• Repro 2: screen recording from the phone, 28 seconds, cut from a longer run, in the same layout. The top of the screen and the keyboard's suggestion row are blurred, and a note covers the panel's first nine steps. At 0:01 the long press selects anchored. At 0:17 Paste puts in anchoredanchored after sync., with the caret between the copies, and at 0:19 z lands there. At 0:21 the tap outside lands on the Edit mode header and the keyboard closes. The paragraph still ends sync.anchoredzanchored. At 0:22 the page jumps down to the buttons, and the paragraph ends sync.anchoredz while the Comment 1 - open card is still shown. At 0:23 Clear comments removes the comment.

Repro 1 — Android Chrome, /examples/plite/plaintext

https://github.com/user-attachments/assets/8be14122-23fd-4f95-9a43-3432d88db664

Repro 1 reference — Android Chrome, slatejs.org/examples/plaintext

https://github.com/user-attachments/assets/a613f87f-f626-449b-8adc-d2c87a2117ee

Repro 2 — Android Chrome, /examples/plite/comment-mode

https://github.com/user-attachments/assets/ad19fc42-c404-41fb-9ba5-856e9f01c7de