Summary

CodeBlockContent.update() ended every render in domNode.innerHTML = code. Assigning innerHTML always destroys and recreates the child nodes, even for a byte-identical string — so a code block tore down the text node the caret was sitting in and built a new one on every single keystroke, and on every render that changed nothing at all (a language switch resolving to the same highlight, a re-render triggered elsewhere, an undo landing on the same text).

Paragraphs never paid this cost: Format.inputHandler calls update() only when checkNeedRender reports a token change, and otherwise moves the caret without touching the DOM.

Change

Compare before writing:

function replaceIfChanged(domNode: HTMLElement, html: string) {
    if (domNode.innerHTML !== html)
        domNode.innerHTML = html
}

• Both render paths (plain and Prism) go through it.
• The trailing-break span ([Bug] code block 中换行不能准确表现 #5114) is now part of the compared string rather than appended afterwards, so a \n-terminated block is idempotent too instead of rebuilding on every pass.
• Search still works: it renders through update(undefined, highlights), which changes the output, so the comparison re-renders — and clears — exactly as before. There is a test for both directions.
• inputHandler's if (needRender) … else … had two identical branches and a // TODO: throttle render standing in for exactly this comparison; both are gone.

What this is not

An earlier revision of this PR claimed to fix #4851 (Japanese IME garbling in a code block) with a debounced re-highlight. That diagnosis was wrong, and the debounce was worse than useless — it only held within a 300 ms window, so ordinary IME typing (which pauses on every candidate selection) fell straight through it.

#4851 turned out to be #3468's mechanism: a code block whose text ends in a newline used to render that newline inside its own <span class="mu-line-end">, the caret landed inside the newline's own text node, and Chromium will not sustain a composition there. #5286 moved the newline back into the main text node and it has been fixed since v0.20.0-rc.2 — verified by running a real CDP-driven composition against the 0.20.0-beta.5 source (garbles) and against current develop (clean). That issue is now closed.

So this PR carries no bug fix. It removes work that was never needed, and the node identity it preserves is a precondition for anything composing against the live DOM.

Tests

Node identity is what a needless re-render destroys, so that is what the tests assert — not rendered values, which two freshly minted nodes compare equal on.

Unit (renderIdempotence.spec.ts) — unchanged render keeps the existing nodes; changed text still replaces them; a \n-terminated block is idempotent; search highlights still render and still clear.

E2E (e2e/tests/typing/codeblock-node-identity.spec.ts) — a real Chromium composition over CDP Input.imeSetComposition. The code block's text node must survive a run of IME commits, including with 500 ms pauses between them, in a Prism-highlighted block, and under plain typing.

Both idempotence unit cases and all four e2e cases fail without the change.

muya unit        1984/1985 (the 1 failure is a worktree-only `?inline` resolution artifact)
muya e2e         typing + blocks 115/115; full chromium run matches the baseline's known local flakes
eslint / tsc     clean
madge --circular clean

🤖 Generated with Claude Code