Rich Markdown Bugs We Fixed

Bugs found in the Rich Editor, what caused each, and why we fixed it the way we did. Older ones are listed in that chapter.

One typed letter rewrote a list higher up the page.

• The issue: typing one letter into a paragraph of Browser-Release-Checks.md also changed a numbered list above it: its wrapped lines lost two of their three spaces of indent. The code span `nibtree@<version>` was saved as an [[ORCA_RICH_MD:...]] placeholder. The corpus test in richEditor.test.ts caught it in CI.
• Why it happened: before the editor reads a file, raw-markdown-html.ts swaps raw HTML for placeholders and skips code spans, so <version> inside backticks stays text. It knew it was leaving a fenced code block on the closing ``` line, but then went on to scan that same line for code spans. The fence's last backtick paired with the opening backtick of the next code span, so from there every code span was read inside out: <version> looked like HTML outside code and got a placeholder that is never put back inside code. The saved text no longer matched the file, so the editor wrote the whole document again in its own style, list indents included.
• The fix and why we chose it: the closing fence line is copied as it is and the scan goes on at the next line. A fence line can hold nothing but the fence, so nothing on it needs scanning. The test in raw-markdown-html.fences.test.ts encodes a code span with a tag after a backtick fence and expects the text back unchanged.

Opening a Markdown file slid the whole window up.

• The issue: on macOS, opening a Markdown file in the Rich Editor moved the whole app up under the title bar, with an empty band under the status bar. The document itself opened scrolled down. Other tabs stayed shifted until the app was restarted.
• Why it happened: ProseMirror keeps the view steady across an update. Where the browser supports CSS overflow-anchor, it leaves that to the browser; elsewhere it records the scrollTop of every ancestor up to the page and writes them back, moved by how far a reference line moved. It checks support with view.dom.style.overflowAnchor == null. WebKit, the macOS web view, has no overflow-anchor, so on load ProseMirror wrote 145px to every ancestor, body included, and each one that could scroll did. Chromium has the property, so the test browser pages never showed it.
• How we found it: trace_scrolls (see Debugging with MCP) around open_file listed a scrollTop write to every ancestor, all from restoreScrollStack in ProseMirror's view.
• The fix and why we chose it: richEditor.ts sets overflowAnchor = "auto" on the editor's element. On WebKit that makes the check false, so ProseMirror stops moving the ancestors; on Chromium auto is already the default, so nothing changes there. Making every app container unscrollable instead would have hidden the next library that scrolls ancestors, not fixed this one.