HTML Quick Look selection cannot be copied on macOS 26.6.1, while RTF works

[jhzhang09]

Description

With the HTML render engine, source text can be visibly selected in Finder Quick Look, but pressing ⌘C does not write the selected text to the system clipboard.

The same file and selected text copy correctly after changing only the render engine to RTF.

This is related to #300, but this report adds a reproducible clipboard control test on the current Syntax Highlight release, an HTML-versus-RTF comparison, and relevant source-path analysis.

Environment

• Syntax Highlight: 2.1.30 (79)
• macOS: 26.6.1
• Test file type: Go (.go)
• Preview entry point: Finder Quick Look (Space bar)

Reproduction

HTML engine

1. Set Render engine to HTML.
2. Select a Go source file in Finder and press Space.
3. Drag-select the first line, package main.
4. Put a known sentinel string, HTML_SENTINEL, on the clipboard.
5. Return to Quick Look and press ⌘C.
6. Paste into TextEdit.

Actual result

TextEdit receives HTML_SENTINEL, not package main.

The clipboard is therefore unchanged by ⌘C, even though:

• package main remains visibly highlighted;
• the macOS accessibility tree reports package main as selected text inside an HTML content element.

This rules out a simple inability to select the source text.

RTF control test

1. Change only Render engine to RTF.
2. Preview the same file.
3. Select the same package main text.
4. Press ⌘C and paste into TextEdit.

Result

TextEdit receives package main correctly.

In RTF mode, the accessibility tree exposes the preview as a native text input area rather than HTML content.

Expected behavior

When source text is visibly selected in an HTML Quick Look preview, ⌘C should place that selected text on the system clipboard, as it does with the RTF engine.

Relevant implementation details in 2.1.30

The Quick Look extension declares a data-based preview:

• QLIsDataBasedPreview = true

On macOS 12 and later, providePreview returns rendered data through QLPreviewReply:

• HTML is returned as UTType.html
• RTF is returned as UTType.rtf

The renderer selects style2.css on macOS 12 and later:

• Stylesheet selection

That stylesheet prevents selection for line-number cells, but not for source-code text. The runtime result agrees: source text is selectable, while copying fails.

I also could not find copy/pasteboard or responder-chain handling in the data-based HTML preview path. Normally macOS Quick Look supplies this behavior, but the current implementation therefore depends on the system HTML preview host routing the copy command correctly.

Likely boundary to investigate

This appears to be a responder-chain or pasteboard-routing compatibility issue between the macOS Quick Look HTML host (including its WebContent process) and the data-based QLPreviewReply path.

This is an inference from the runtime comparison and source path, not a confirmed macOS bug.

Possible focused experiments:

1. Check whether the generated HTML document receives the copy keyboard event and whether a JavaScript copy handler can write the current selection.
2. If the data-based HTML host does not route copy reliably, evaluate an owned WKWebView preview path that participates in the responder chain and explicitly implements copy using the current selection and NSPasteboard.
3. Add a regression test that verifies the resulting pasteboard contents, rather than checking only that selection is visible.
4. Keep the current RTF path unchanged, because it already provides the expected copy behavior.

An owned WKWebView would be a broader change than the current data-based preview, so testing whether a smaller HTML-side compatibility fix is possible first may reduce regression risk.

Workaround

Switching the render engine to RTF restores copying on this system.