Fixes #5415.

The bug

Deleting a selection that spans two blocks with Cmd+Backspace removed the second block from the screen but not from the document. The block stayed in muya's tree with its DOM node detached, so the next structural edit nearby — Enter, Enter at the end of a bullet list — threw NotFoundError: Failed to execute 'insertBefore' on 'Node'. One of the triggers behind #5035.

Root cause

muya cuts a cross-block selection only from its document keydown handler, and shouldCrossBlockCut() refuses every chord carrying Cmd or Ctrl — a guard added so Ctrl+C would stop silently deleting the selection (#3491).

A key alone cannot say whether a modifier combo edits. Several of the refused chords are editing commands, and some edits carry no keydown at all:

Chromium then applied the edit across the block elements and removed the ones in between, leaving muya's tree and json state holding a block whose element is gone.

Fix

Add a beforeinput handler alongside the existing keydown one. beforeinput fires for every editing intent whatever produced it, and its inputType says whether the event edits at all — so non-editing shortcuts need no blacklist (they fire no beforeinput), and the modifier guard stays exactly as it is for #3491.

The two handlers never act on the same edit: anything keydown took over arrives at beforeinput with the selection already cut, or does not arrive because keydown cancelled the event. So the new handler only ever sees what the old one missed.

crossBlockReplacement() is one rule — over a cross-block selection muya owns every editing beforeinput except the ones another handler already owns:

• deleteByCut / deleteByDrag / insertFromPaste / insertFromPasteAsQuotation / insertFromDrop / insertParagraph / insertLineBreak / the two composition types are excluded — the cut, paste and Enter paths own them, and composition is not cancelable.
• everything else classifies as insert or delete and replaces the selection accordingly.

Stating it as an exclusion set rather than an allowlist matters: an inputType nobody has enumerated (a future Chromium addition, a route no one reported yet) then degrades to "selection replaced" instead of to the corruption above, and the set does not grow a row per bug report. classifyInputKind() already splits insert from delete for undo grouping, so that stays one definition.

Why not just widen the keydown guard?

Measured, same spec, three implementations:

Two reasons the key layer cannot get there:

1. An allowlist only answers half the question. It decides whether to cut; it does not decide whether the browser's own action must then be suppressed. Insertions must be allowed to complete (that is how the existing printable-key branch works, and why ⌃Y passes above); deletions must be cancelled, or they delete a second time on top of the cut — hence - tw / - twt / - txt. That needs a second hand-maintained table.
2. The same chord means different things per platform. On Linux/Windows Ctrl+K, Ctrl+D, Ctrl+H and Ctrl+Y are MarkText's own shortcuts (view.toggle-toc, format.strike, paragraph.bullet-list, format.inline-code — see keybindingsLinux.ts), so allowlisting them by key would reintroduce In Typewriter Mode, when I selected text, and somehow text would be disppeared #3491 on a different key. beforeinput needs no table: those chords fire no beforeinput on Linux, and arrive as deleteContentForward etc. on macOS.

The keydown path stays, and must: IME composition reaches beforeinput as insertCompositionText, which is cancelable: false. The keydown fallthrough (cut without preventDefault, before compositionstart) is the only hook that can collapse the selection in time. The two handlers are complementary, not redundant.

Verification

Measured in Chromium via the muya e2e host. Document - one / - two / blank / text, selection from tw|o into te|xt:

Each case then runs Enter, Enter at the end of the list and asserts no pageerror, no detached block, and that the block tree still matches getState(). Without the fix that step throws the reported insertBefore error.

Tests

• e2e/tests/editing/cross-block-modifier-edit-5415.spec.ts — the chords above, plus two guards that must not change: Ctrl+C still leaves the selection alone (In Typewriter Mode, when I selected text, and somehow text would be disppeared #3491) and a printable key still replaces it. Playwright only forwards macOS AppKit editing commands when the host is macOS, so the mac-only chords are gated on the platform; Ctrl+Backspace needs no such command and is what covers this on CI.
• src/clipboard/__tests__/crossBlockReplacement.spec.ts — the inputType decision table, including that formatting and history commands never delete, and that an unrecognised type is still claimed.

Suite results: muya clipboard units 171 passed; muya e2e editing/ 111 passed. The one red spec there, cross-block-enter.spec.ts:36, fails identically on unmodified develop in this environment and is unrelated.

Also in this PR

• replaceRange() in cut.ts — cutSelection's same-block branch and the new insertTextAtCursor() were the same splice; they are one implementation now.
• e2e/tests/helpers/tree.ts — detachedBlocks / expectTreeMatchesJson / the Enter-twice probe are a single "the browser left a block behind" assertion that Unexpected error with message Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node. #5035's spec owned privately. Shared, and Unexpected error with message Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node. #5035 switched over.
• The beforeinput handler short-circuits on the native selection being collapsed before resolving muya's, so ordinary typing does not pay for getSelection() (which materialises the block list per endpoint via LinkedList.offset).

Not covered

The emoji picker / dictation / handwriting routes named in the issue go through the same insert branch, but I could not verify them: document.execCommand('insertText') fires no beforeinput at all, so it is not a faithful stand-in, and those input sources cannot be driven from a test. Ctrl+Y is the one insertion route reachable from a keyboard, and it is what the spec exercises.

🤖 Generated with Claude Code