fix: preserve whitespace-only plain text paste - #4706

Thanks for the fix! I verified it locally by driving the real paste path in a headless Chromium (the muya e2e harness: navigator.clipboard.write([ClipboardItem]) + a real Cmd/Ctrl+V, i.e. the same code path real users hit) against this branch's paste.ts.

TL;DR: the fix engages only when the clipboard carries text/plain alone. As soon as the clipboard also carries a text/html slot — which is what virtually every real "copy spaces from a browser / Word / another editor (and muya's own copy)" produces — the new branch is bypassed and the paste is still a no-op. That's almost certainly why it appears to "have no effect" when tested by hand.

Pasting two spaces at A|B:

Root cause. getCopyTextType returns 'html' whenever html && text are both truthy:

// utils/paste.ts
if (pasteType === PasteType.NORMAL)
    return html && text ? 'html' : getTextType(text)

For two spaces, text is truthy and the normalized html is usually still non-empty, so copyType === 'html'. The new guard hard-requires copyType === 'text', so it never engages — the paste falls through to applyParsedPaste, whose markdown.trim().length === 0 early-return drops it.

Why CI stays green. The regression test feeds makePasteEvent({ 'text/plain': ' ' }) — no text/html slot — so it only exercises the one path that already works and never sees the multi-slot clipboard real users have.

Suggested fix. Base the decision on the intent ("a plain inline-whitespace paste"), not on copyType, and insert the original text (the html→markdown product may have dropped the spaces via turndown):

const isPlainInlineWhitespace
    = text.length > 0
        && text.trim().length === 0
        && !text.includes('\n')

if (isLiteralAnchor || isPlainInlineWhitespace)
    applyLiteralPaste(clipboard, ctx, isPlainInlineWhitespace ? text : markdown)
else
    applyParsedPaste(clipboard, ctx, markdown)

Adding a regression test that sets both text/html and text/plain would have caught this and would lock the real fix in place.

Minor, while here: …trim().length === 0 also treats \t / \xa0 as whitespace, so a lone tab routes to literal insertion as well; a leading literal tab can be re-read as an indented code block on the next markdown round-trip. Narrowing to actual spaces (e.g. /^ +$/.test(text)) sidesteps both this and the html issue above.

Thanks, this review was right. I rechecked the real paste path and the previous fix was too narrow.

Root cause:

getCopyTextType(html, text, PasteType.NORMAL) returns html whenever both text/html and text/plain are present. Real sources such as browsers and editors usually put both formats on the clipboard, so the previous copyType === 'text' guard was bypassed. The paste then went through the HTML-to-Markdown path and finally reached applyParsedPaste(), where whitespace-only markdown is treated as empty and dropped.

Updated fix:

The special case now checks the original plain text payload instead of copyType or the HTML-derived markdown:

const isPlainInlineSpaces = /^ +$/.test(text);

When that is true, the paste uses literal insertion with the original text/plain value. This preserves spaces even when the clipboard also contains text/html. I intentionally narrowed this to ASCII spaces only, so tabs are not routed through this literal whitespace branch and cannot become an indented-code edge case on a later Markdown round trip.

Tests added:

• A unit regression for text/html: '<span> </span>' plus text/plain: ' '.
• A Chromium e2e regression that writes a real ClipboardItem with both text/html and text/plain, focuses the editor, and sends a real paste keystroke.

Validation:

pnpm --filter @muyajs/core test -- src/clipboard/__tests__
pnpm --filter @muyajs/core lint:types
pnpm --filter @muyajs/core lint
pnpm --filter muya-e2e e2e:chromium -- tests/editing/clipboard.spec.ts
pnpm --filter @muyajs/core exec vitest run --testTimeout 20000
pnpm typecheck
git diff --check