feat(copy): copying from the preview keeps its formatting (#674)

[PathGao]

What this is

Closes #674, reported by @yvesll: selecting in the preview and copying put only plain text on the clipboard, so a paste into Word or Mail lost every heading, bold run and link.

⌘C in the preview now writes text/html beside text/plain. A pasted selection keeps its headings, emphasis, lists, tables and links, resolved by the receiving application's own styles.

This is the product question #549 deliberately left open — it fixed which code writes the clipboard, and left "plain or rich" for later, with a test forbidding a rich flavour until someone decided. Decided: a preview is rendered content, and copying rendered content is expected to keep its formatting. It is what a browser does, and what the reporter cited VS Code's own Markdown preview for.

Mechanism

Writing the flavour ourselves is what preserves #549's result. The native copy is still cancelled before WebKit's Editor::copy reaches its subresource sweep, so the 19 MB WebArchive that measurement found is still never built; what lands on the clipboard is two strings this handler produced.

Three things in the preview's DOM are not structure and had to be resolved before the fragment leaves the app, because the clipboard carries no stylesheet:

• KaTeX renders every formula twice — MathML for screen readers, positioned spans for the eye — and hides one in CSS. Pasted somewhere without that CSS, both are visible and the formula reads twice. The visual half stays.
• The fold chevrons are controls. @media print already removes them for the same reason.
• An image's src is an asset:// URL (http://asset.localhost on Windows), a scheme that exists only inside this app. It becomes a file: URL, via the same resolveExportImagePath the HTML export uses, so document-relative and absolute sources resolve identically in both.

The find that changed the shape of this PR: katex/contrib/copy-tex was installing a second copy listener. It fires only when the selection contains math, rewrites both flavours from a fragment of its own, and — being registered later, since it is a lazy import — runs last and wins. Traced through setData during a real copy event, with the first version of this change in place:

text/plain  <- handleCopy                    (54 chars)
text/html   <- handleCopy                    (545 chars, pruned)
text/html   <- katex copy-tex.js:89          (898 chars, unpruned)
text/plain  <- katex copy-tex.js:90          (50 chars)

So every pruning above would have been silently undone for any selection containing a formula, and its text/html — which has been reaching the clipboard all along, unnoticed, since only math selections trigger it — is the doubled-formula one. The extension is no longer loaded; its two behaviours worth keeping live in utils/previewCopy.ts: a selection that starts or ends inside a formula expands to the whole formula, and the plain text of a formula is its TeX source rather than the glyph soup ($E=mc^2$, not E=mc2).

Measured end to end, dispatching a copy over a rendered document and reading the flavours back:

	before	after
flavours written	text/plain (text/html too, but only when the selection had math)	text/plain, text/html
<strong>, <h2> in the HTML	—	preserved
KaTeX MathML duplicate	present	removed
fold chevrons	present	removed
image src	asset://localhost/…	file:///Users/me/notes/img/shot.png
formula in the plain text	$E=mc^2$	$E=mc^2$

Scope

file: rather than a data URI. Embedding the bytes means reading the file, which is a Tauri round-trip, and a copy handler has to write synchronously — that needs navigator.clipboard.write with a ClipboardItem promise, a different clipboard API with its own permission and user-gesture behaviour in each webview. file: costs nothing and works in the desktop applications this issue names; it will not work when pasting into a browser-based editor like Google Docs, which cannot open local files, and it will not survive being pasted on another machine. Worth doing properly if someone asks — as its own change.

Syntax highlighting does not survive either: highlight.js colours through CSS classes, and inlining those colours is the same "serialize a fragment as a standalone document" work. Code blocks keep their structure and monospace, not their palette.

Mermaid diagrams are left exactly as they render, inline SVG. What a receiving app does with that varies and is not something this change can decide.

The plain text of a selection containing math is built from the fragment's text content, which loses the blank lines between blocks. That is inherited exactly — it is what copy-tex did, so no selection copies differently than it did before — and it is why the no-math path still reads Selection.toString(), which is the only source that knows what is rendered.

Not touched: the editor's copy, which is Monaco's own path on Rust (#548), and Edit ▸ Copy in the menu bar, which lands in this same handler and therefore gains the same behaviour.

Tests

scripts/previewCopyHtml.spec.ts (vitest, needs a DOM) runs the real functions over fragments and selections: structure preserved, formula carried once, chevrons dropped, asset:// and http://asset.localhost and document-relative sources all becoming the same file: URL, spaces and # surviving as percent-escapes, remote and data: sources untouched, TeX as the plain text for inline and display formulas.

scripts/previewCopyPlainText.test.ts is renamed previewCopy.test.ts and its contract updated — the assertion that no rich flavour may exist was #549's placeholder for this decision, and it is replaced by the two that matter now: the HTML is the one this handler built, and nothing else in src installs a copy listener. That last one is what keeps copy-tex from being reintroduced and quietly restoring the fight.

Revert the flavour write and keep the tests: the spec goes red on every assertion about HTML, and the handler tests go red on the flavour and single-decision assertions.

Verification

npm audit             0 vulnerabilities
npm run check         804 files, 0 errors, 0 warnings
npm test              931 pass, 0 fail
npm run test:vitest   42 files, 376 pass
cargo test            148 pass

The table above was measured in Chromium against the dev server, with window.__TAURI_INTERNALS__ stubbed so the frontend boots outside Tauri and render_markdown returns a fixture — including real KaTeX output, since the annotation the TeX substitution reads only exists after KaTeX renders in the DOM.

What that does not cover: what any receiving application actually does with the HTML. Nobody has pasted this into Word, Mail or Google Docs — the flavours on the clipboard are verified, their interpretation is not. Nor is WKWebView or WebView2 behaviour: the handler is plain DOM and the same code runs everywhere, but the measurements are Chromium's.