Editor textarea: short content unless a screen reader is attached (fixes IME jitter in WebKit)

[PathGao (PathGao)]

Fixes microsoft/monaco-editor#4796 — "line jump up and down when type chinese, only in safari".

What happens

In browsers without EditContext (WebKit, Firefox) the editor takes input through TextAreaEditContext. During IME composition the textarea becomes a one-row overlay on the composed line, but it holds a page of text, so _render scrolls it to the caret's row: scrollTop = nlBefore * lineHeight.

WebKit then scrolls that textarea itself, on every composition update, by the minimum needed to keep the caret visible — which is a few pixels short of row-aligned because the caret box is shorter than the line box. The next render writes the row-aligned value again. Instrumented on macOS (Monaco 0.55.1 in WKWebView, lineHeight 21, caret on line 2 of the page):

compositionupdate "a j"
  WRITE  top 21 -> kept 21   [scrollHeight 42, clientHeight 21, max 21]   not clamped
  SCROLL top 18              (asked 21, off by 3)                          the element scrolls itself
  WRITE  top 21 -> kept 21                                                 next render

102 self-scrolls over three composed lines, every one off by exactly 3px (line 3: 42 → 39). The first line of the page never jitters because its target offset is 0. "editor.accessibilitySupport": "off" removes it entirely, because that path writes a short single-line string into the textarea and nothing needs scrolling. Full trace in the issue.

The change

writeNativeTextAreaContent already treats AccessibilitySupport.Unknown as "no screen reader": it skips render-time writes unless isScreenReaderOptimized() (#192278). getScreenReaderContent made the opposite call for the same state and handed it the paged content. This aligns the two: Unknown gets the short content the Disabled branch already produces, and the textarea is not sized for wrapping either. With no overflow there is nothing for the browser to scroll and nothing to fight over.

Android is left exactly as it was: its Unknown case still reaches the Android word branch that composition diffing relies on (the first review caught that the initial version returned EMPTY before it).

Enabled — a screen reader known to be attached, or "editor.accessibilitySupport": "on", which is what the docs ask screen-reader users on the web to set — is untouched.

Second commit: write order in the composition branch

The composition branch of _render wrote scrollTop/scrollLeft before _doRender sized the textarea, while the non-composition branch a few lines down writes them after. A scroll offset is clamped against the element's size at the moment it is written, so the sibling branch's order is the one that cannot lose part of the write. This was the first thing I tried against the jitter and it made no measurable difference on its own (the offsets were never clamped; they were moved afterwards — see the issue), so it is here as consistency, not as the fix.

Things I tried first, and why they are not the fix

• Writing the two offsets after _doRender (the sibling non-composition branch does it in that order): no effect. The write is never clamped; the value is moved afterwards.
• Re-asserting the offsets from the textarea's scroll event: removes the jitter, but keeps the alignment depending on a value the browser owns.
• Repositioning the overlay to follow the browser's scroll: moving a focused editable makes WebKit reveal its caret again through the ancestors, and the whole editor scrolls — worse, and no longer IME-specific.
• Giving the overlay its full content height and clipping to one row: works in principle, but _doRender couples height and line-height, and the change is much larger than this one.

Verification

Built Monaco with this exact change into the app that reproduces the issue (macOS 26, WKWebView, system Chinese IME): composition on any line no longer jitters, ASCII typing, select-all, copy, paste, undo and cross-line cursor movement behave as before. src/vs/editor/test/browser/controller/textAreaInput.test.ts mocks getScreenReaderContent, so no existing assertion covers this decision.

Not verified: Firefox (the other browser on this code path) and screen-reader behaviour with Unknown — by design that case now behaves like Disabled, which is the everyday desktop path without a screen reader.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The new condition bypasses required Android composition handling when accessibility support is unknown.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Aligns textarea content and wrapping with confirmed screen-reader support to prevent WebKit IME jitter.

Changes:

• Uses short textarea content unless accessibility support is enabled.
• Restricts textarea wrapping to screen-reader mode.

File summaries

File	Description
src/vs/editor/browser/controller/editContext/textArea/textAreaEditContext.ts	Updates textarea content and wrapping behavior.

Review details

Suppressed comments (1)

src/vs/editor/browser/controller/editContext/textArea/textAreaEditContext.ts:571

• This inline explanation exceeds the project's one-line limit for comments inside methods. It can be stated concisely without restating the preceding screen-reader wrapping rationale.

		// Without one, the textarea only ever holds the short content `getScreenReaderContent` writes,
		// and there is nothing to wrap.

• Files reviewed: 1/1 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[PathGao (PathGao)]

@microsoft-github-policy-service agree

[PathGao (PathGao)]

Addressed in 9b39c2c: the Android cases now behave exactly as before — Unknown on Android still reaches the word branch, only the non-Android Unknown case takes the short content — and the in-method comments are one line each.