[Beta]: On Android Chrome, Copy after typing writes nothing to the clipboard, so Paste inserts the previously copied word

Start with the Android Chrome reproduction on /examples/plite/huge-document, then read packages/plitejs/src/react/editable/clipboard-input-strategy.ts at applyEditableCopy and packages/plitejs/src/dom/plugin/dom-clipboard-runtime.ts at writeDOMSelectionData and writeDOMRangeData. Check whether the model selection matches the browser selection when the second copy event fires after typing, and trace whether clipboard data is written. Done means copying cognatus after typing replaces the clipboard word on Android Chrome; keep the separate paste duplication bug #5262 out of scope.

Testing lane

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

Summary

On /examples/plite/huge-document in Android Chrome, after a few characters are typed in the editor, a long press on another word and Copy leave the clipboard unchanged. Paste then inserts the word copied before, not the new one. On slatejs.org the same steps copy and paste the new word.

Reproduction

Repro 1: /examples/plite/huge-document, Android Chrome

The first block of the editor is the heading Suppellex a cognatus arca aliquam audentia..

1. Open https://beta.platejs.org/examples/plite/huge-document.
2. Tap Configuration and Statistics above the editor to fold those panels, so the keyboard does not cover the text.
3. Tap the end of the first block.
4. Long-press aliquam and tap 复制 (Copy).
5. Tap the end of the first block, and type 你好 with pinyin (nihao).
6. Long-press cognatus and tap 复制 (Copy).
7. Tap the end of the first block, long-press there and tap 粘贴 (Paste).

In step 6 the long press selects cognatus, and the menu offers 复制 (Copy) as usual. In step 7 Beta pastes aliquam, the word from step 4, and the block ends 你好aliquamaliquam. The paste also goes in twice. That is a separate Android paste bug, #5262, and this issue is only about which word is pasted. On https://www.slatejs.org/examples/huge-document the same steps paste cognatus, and the block ends 你好cognatus.

The agent also logged the page's clipboard events. The first copy wrote text/plain, text/html and the editor's own fragment to the clipboard. The second copy fired a copy event while the browser's selection in the page was cognatus, but no data was written.

The same run found that the second copy works when nothing is typed between the two copies, and that typing English letters in step 5 breaks it the same way as pinyin. Copy also works in desktop Chrome. These variants were not recorded.

Expected

Copy writes the word that is selected when Copy is tapped, so Paste inserts cognatus, as on slatejs.org.

Actual

The copy event fires, but nothing is written. The clipboard still holds aliquam, and Paste inserts it.

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 drove natamox's real phone on 2026-10-23 (PT), with slatejs.org as the reference. This was not a test by hand, and nobody has retested it by hand.
• Only /examples/plite/huge-document was tested. Nobody has tried these steps on iPhone or iOS Safari.

Caveat

• Nobody has traced the cause. From a reading of the code on next, applyEditableCopy (packages/plitejs/src/react/editable/clipboard-input-strategy.ts:330) calls preventDefault on the copy event, then writes the clipboard from the editor's model selection through writeDOMSelectionData (packages/plitejs/src/dom/plugin/dom-clipboard-runtime.ts:499). writeDOMRangeData returns without any setData call when that selection is collapsed and not on a void (dom-clipboard-runtime.ts:539). If the model selection is still the collapsed caret left by typing, the page writes nothing, and Chrome's own copy has already been blocked.
• That the long-press selection did not reach the editor's model is an inference from the event log: copy fired and setData was called 0 times. Nobody read the model selection at that moment.

Evidence

• Repro 1: screen recording from the phone, 42 seconds, with an English step panel beside it. The keyboard's suggestion row is blurred. At 0:08 aliquam is selected and the menu shows 复制 (Copy). By 0:21 你好 is committed at the end of the first block. At 0:23 cognatus is selected with the same menu, and the selection clears at about 0:26 when Copy is tapped. At 0:32 the long press at the end shows 粘贴 (Paste), and at 0:37 the block ends 你好aliquamaliquam. The red note at step 7 of the panel comes from the event log, not from anything on screen. The pasted word is the old aliquam; that it goes in twice is #5262, and a gray note in the panel says so from 0:38.
• Repro 1 reference: slatejs.org with the same steps, 55 seconds, in the same layout. At 0:07 aliquam is selected, by 0:24 你好 is committed, and at 0:26 cognatus is selected. At 0:50 Paste puts cognatus after 你好, once.

Repro 1 — Android Chrome, /examples/plite/huge-document

https://github.com/user-attachments/assets/a05ad4e0-551f-4c46-9c17-24bd3497e1a2

Repro 1 reference — Android Chrome, slatejs.org/examples/huge-document

https://github.com/user-attachments/assets/08b908d4-28b3-4665-b4f0-a5fbf08ffdec