Fixes #5114

In a code block, type a line and press Enter twice: the caret should be on line 3, but it stays on line 2. While testing this branch a second defect on the same empty lines turned up — arrow keys there left the code block — and it is fixed here too.

Root cause

A newline with nothing after it lays out no line. The code block compensated by wrapping its final \n in a display: block mu-line-end span (getHighlightHtml(…, handleLineEnding)), and that only works when the text before the newline does not end in one as well. Measured in Chromium:

With no line box to sit on, the caret is drawn on the line above. The same gap made ArrowDown onto the empty last line type at the end of the previous line: hello\nabc + ArrowDown + q gave hello\nabcq\n.

Fix

CodeBlockContent.update() appends <span class="mu-trailing-break"><br></span> whenever the text ends with a newline. The text node — and so textContent and every offset — is unchanged. Two constraints shape it:

• Added after highlighting. Prism's keep-markup plugin re-inserts preserved elements by text position and never matches a zero-width element at the very end of the text, so a <br> in the pre-highlight HTML is dropped.
• Wrapped in a span. Chromium puts the caret just before the <br>, inside its parent. For a bare <br> that is (content, 1), which TextSelection.getSelection reads as text offset 1 — clicking the last line and typing produced hzello. Inside the wrapper the caret is at (wrapper, 0), which resolves to the text length.

The IME composition anchor from #5281 is now seeded ahead of the trailing break; appended after it, the composition started a line below the caret.

getHighlightHtml loses its handleLineEnding path, which only the code block used.

Measured and rejected

Arrow keys on empty lines

In hello\nworld\n with the caret on the empty last line, ArrowUp left the code block for the language input instead of moving to world; from an empty middle line, ArrowDown left it the other way. This predates the branch.

Content.arrowHandler measures the caret to decide whether it is on the block's first or last line. A caret on an empty line has no client rect, and the failed measurement reads as both. In a code block a newline on the caret's side already answers the question, so CodeBlockContent.arrowHandler leaves those keys to the browser and defers to Content.arrowHandler otherwise — including a wrapped first or last line, which still needs the measurement.

Tests

• e2e/tests/blocks/codeblock-trailing-newline-5114.spec.ts (Chromium)
  • lines drawn and the line the caret is painted on after Enter ×2, after Enter in an empty block, and in a Prism-highlighted block. A collapsed range right after a newline has no client rects, so the caret is found in a screenshot: glyphs transparent, caret painted red, caret-animation: manual;
  • click and ArrowDown onto the empty last line, then type;
  • ArrowUp from the empty last line and ArrowDown from an empty middle line stay in the block; ArrowUp on the first line still leaves it;
  • an IME composition on the empty last line via CDP Input.imeSetComposition.
• codeBlockContent/__tests__/trailingNewline.spec.ts (jsdom) — a trailing break only after a final newline, textContent unchanged, kept on highlighted blocks, the IME anchor seeded ahead of it.
• codeBlockContent/__tests__/arrowHandler.spec.ts (happy-dom, which like Chromium on an empty line gives the caret no rect) — which arrow keys are left to the browser and which still go through Content.arrowHandler.

Verified

Both IME guards fail with the anchor change reverted. tsc --noEmit and ESLint (0 errors) are clean, and the codeBlockContent / base arrow-navigation / table-cell arrow / HTML-block arrow unit suites pass. Locally the blocks, diagrams, typing and options E2E directories pass except search-replace ×2 and the ime.spec table-cell case — which fail identically on unmodified develop in the same setup — and the first two options/autopair cases, which type into a paragraph and never reach this code.

Found along the way, not changed here

• A new code block can drop the caret of the first keystroke. With code-block line numbers enabled (off by default), a new code block re-renders on its first animation frame to fill the gutter (codeBlock/index.ts). A keystroke landing before that frame loses its caret to the start of the block, and the rest of the word is typed in front of it: hello becomes elloh. Seen only in automation under heavy parallel load (22 of 32 runs at 4 workers); not reproduced at typing speed, even with 20× CPU throttling. The E2E spec waits a frame after creating a block.
• TextSelection.getSelection reads an element-level boundary (content, n) as text offset n rather than the length of the text before child n. No normal editing path on develop is known to produce such a boundary — the bare <br> above did. To see it: in a code block containing hello world, set the selection to (codeContent, 1) (the end of the text), press Shift, then type Z — the result is hZello world.

🤖 Generated with Claude Code

https://claude.ai/code/session_013QodFHUNmHeC8NhrHSYeXk