docs/solutions/logic-errors/2026-04-26-slate-browser-native-multiline-paste-success-must-block-fallback-insertion.md
Generated browser stress caught a false negative in the public paste helper. The helper judged native multiline paste by raw model text, missed that the browser had already split the payload into blocks, and then inserted fallback text on top of the successful paste.
bun test:stress failed on the plaintext multiline paste row.["Alpha", "Beta"].["Alpha", "BetaAlpha\nBeta"].modelText.includes(text) was too narrow for multiline paste.
Browser editing can convert one clipboard string into multiple rendered
blocks, so the original multiline string may not appear literally in the
model text even when paste succeeded.Teach paste helpers to detect successful multiline paste through rendered block text before falling back:
function didPasteApplyText(root: Locator, modelText: string, text: string) {
if (modelText.includes(text)) return true;
const blockText = getBlockTexts(root).join('\n');
return blockText.includes(text);
}
Use that guard in both text and HTML paste helpers before fallback insertion.
The browser-visible contract is block-oriented for this case. A multiline paste can be correct even when the exact clipboard string is not present as one model substring. Joining rendered block text gives the helper a cheap, public signal that native paste already landed.
This keeps the fallback path useful for browsers that do not apply the paste, while preventing duplicate insertion when the browser did apply it.
docs/solutions/logic-errors/2026-04-04-public-paste-helpers-should-use-real-clipboard-write-plus-real-paste-gesture.mddocs/solutions/logic-errors/2026-04-25-slate-v2-destructive-delete-must-clean-empty-leaves-before-render.md