Summary

Triple-clicking a line highlights only that line, but typing a character also consumed the block below it: a thematic break disappeared, a list's first item or a quote's text was pulled into the line, front matter absorbed the body paragraph and lost its own. Above a table or a task list the screen changed but the document did not, and above a heading the triple-click highlighted nothing at all and the character landed at the start of the line.

All nine variants in #5389 now behave as that issue's "Expected result" column specifies, verified in the packaged app with the file re-read from disk.

Root cause

muya consumed the browser's select-paragraph range as if the user had made it. Captured from a real Chromium, that range reaches past what it highlights, and where it reaches depends on what follows the clicked line:

TextSelection.getSelection() calls a selection cross-block on block identity alone, so the first row became a cross-block selection. Clipboard.keydownHandler then ran cutSelection, and resolveCutEnd with an end offset of 0 returns the end block's entire text as the tail to merge into the start block before removing it — so a block the user selected no character of was absorbed whole. In the second row findContentDOM (upward-only) resolved nothing, getSelection() returned null, and the keystroke neither cut nor called preventDefault(), leaving the browser to edit the DOM with the document behind it (#5414, one of the #5035 insertBefore triggers). The third row explains the heading case, and the fourth joined two lines of one code block.

The same selection fed Ctrl+X, paste (applyPaste delegates to cutHandler) and Enter, and because the line read as cross-block, Editor._dispatchEvents nulled activeContentBlock — which is why Cmd+B and the inline format toolbar did nothing over a triple-clicked line in a multi-block document. The existing triple-click specs use single-paragraph documents, where the range has no block to spill into, so none of this was covered.

Fix

Don't consume that range — cancel it. The third mousedown of a click streak is default-prevented, the clicked line is located from the pointer's own coordinates (caretPositionFromPoint, falling back to caretRangeFromPoint), and muya sets the selection itself:

if (!isMouseEvent(event) || event.button !== 0 || event.detail < 3)
    return

const line = lineAtPoint(this._doc, event.clientX, event.clientY)
if (!line)
    return

event.preventDefault()
this._selectInfo.isSelect = false
line.block.setCursor(line.start, line.end)

Both guards are measured, not defensive: a right-click streak really does arrive with detail = 3, button = 2, and excluding a shift-held streak would re-open the bug — Chromium's third shift-click discards the extension and select-paragraphs at the click, overshoot included. Eleven lines, and that is the whole behavioural change — handleMouseupOrLeave and handleMousemoveOrClick are untouched. Because no engine range is left to correct, the four shapes in the table above stop existing rather than being repaired: the collapsed cases, the unresolvable ones and the \n overshoot inside a multi-line block are all covered by one rule, a triple-click selects the line under the pointer. All three engines then agree, where before Chromium selected a paragraph-and-a-bit while Firefox and WebKit selected the clicked word.

Two supporting extractions, each its own commit: lineBounds (shared with codeBlockContent's getIndentSpace, which had the same off-by-one spelled out by hand) and resolveEndpoint (lifted out of getSelection(), which was the only place that knew how to turn one DOM position into a block and a character offset). lineAtPoint sits beside it in selection/dom.ts, and the selection is installed with Content#setCursor, the API that already existed for exactly this.

The cost: a triple-click no longer extends as the pointer drags on. Cancelling the mousedown leaves the browser's drag-select unarmed — measured: mid-drag the DOM selection stays exactly what we set and the browser never touches it again. The selection therefore stays the clicked line, which the e2e pins in all three drag directions rather than leaving it to chance. Re-arming that gesture would mean owning drag-extension and edge auto-scroll, which is not worth it for this one gesture; nothing is corrupted by its absence.

Two consequences worth calling out:

• A triple-clicked line now behaves like any same-block selection, so an auto-pair character wraps it (* over alpha beta gives *alpha beta*) rather than replacing it — the same thing a drag-selected line has always done.
• Copying a triple-clicked line yields the line, without the trailing \n\n getSelectedText() used to append.

Test plan

• e2e e2e/tests/editing/triple-click-line-5389.spec.ts (Chromium, 22 cases) — the real gesture over twelve following block types, plus a front-matter line, one line of a multi-line code block, a list item, a quoted line, Backspace, a shift-held click streak, [Bug] Typing over a triple-clicked line above a task list or table detaches it, and Enter on a list then throws "Failed to execute 'insertBefore'" #5414's own reproduction through to the Enter that used to throw insertBefore, and the three drag directions. Asserts getMarkdown() and an empty pageerror log.
• Unit src/selection/__tests__/lineAtPoint5389.spec.ts + src/utils/__tests__/lineBounds.spec.ts (19 cases) — lineBounds across single-line, multi-line and empty text; resolveEndpoint resolving a text node and returning null for a table, a task-list item and a detached node; lineAtPoint bounding the first, middle and last line of a code block, and declining when the caret lands outside any content block. happy-dom has no layout, so the caret position is handed in; the gesture itself is the e2e's job.
• pnpm -C packages/muya test (2032 tests), lint, lint:types, check-circular.
• Full Chromium e2e: 391 passed, 2 failed. Which two drifts run to run on this machine (diagrams/plantuml, which reaches plantuml.com; edges/empty-and-tiny; inline/format-toolbar; inline/shortcuts); run in isolation the failing set is byte-identical with and without this branch, and identical again on develop.
• Packaged app (pnpm run build:unpack): issue [Bug] Typing over a triple-clicked line swallows the next block (thematic break, list item, quote, front matter) #5389's steps 1–5 for variants A–H plus a code-block line, driven through the real MarkText window, each asserting the file on disk after File > Save — x plus the untouched block, for all nine. A selection-heavy desktop e2e subset (editor input, inline format, selection word count, tab-switch cursor, search prefill, TOC active heading, paragraph blocks — 47 tests) passes against the refactored getSelection().

Two follow-ups this deliberately leaves alone, both pre-existing and both verified in a real Chromium while reviewing this:

• A double-click in the blank space right of a short line produces the same overshooting range at detail === 2 — zero-width highlight, and one keystroke eats the block below (alpha beta + *** → alpha betaZ***). The same cancel-and-select approach fits, but its no-drag half needs word bounds rather than line bounds.
• A plain drag (no click count) that ends over a table leaves the screen and the document disagreeing — the "native edit muya never intercepts" family, whose fix is a guard in Clipboard.keydownHandler. That belongs to [Bug] Cmd+Backspace across two blocks detaches the second block, and Enter on a list then throws "Failed to execute 'insertBefore'" #5415.

Fixes #5389
Fixes #5414

🤖 Generated with Claude Code