Repository navigation
Conversation
Co-Authored-By: Claude Code <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When composition (IME input) starts or updates while the viewport is scrolled into the scrollback, the helper textarea — and with it the IME candidate window — stays frozen at a stale position:
_syncTextAreais guarded byisCursorInViewport(CoreBrowserTerminal.ts), so the resync added in fix(ime): resync textarea position when composition starts #5759 is a no-op when the cursor row is scrolled out of view.CompositionHelper.updateCompositionElementshas the same guard, so everycompositionupdate/onRenderreposition is skipped as well.Regular keystrokes recover from this state because
_keyDownscrolls to the bottom on user input (scrollOnUserInput). Composition events never go throughonData, and thekeydown(keyCode 229) that would normally trigger that scroll is not guaranteed to cover the composition path:keydownon some platforms — observed with a runtime probe on macOS 26 WKWebView).customKeyEventHandlerbefore the scroll branch runs.compositionupdate.Fix
Mirror the
scrollOnUserInputbehavior of_keyDownin thecompositionstartandcompositionupdatelisteners, before_syncTextArea/updateCompositionElementsrun. This makes theisCursorInViewportguard hold by construction when composing, instead of relying on a preceding keydown:With
scrollOnUserInput: false(or when already at the bottom) nothing changes.Test
3 new integration tests in
test/playwright/Terminal.test.ts(IME compositiondescribe), verified red on master and green with the fix, on Chromium/Firefox/WebKit:compositionstartscrolls to bottom when composing from the scrollbackcompositionupdatescrolls to bottom when scrolled up mid-compositioncompositionstartdoes not scroll whenscrollOnUserInputis disabledNote the setup scrolls with the mouse wheel rather than the
scrollLinesAPI: the API path goes through the viewport's smooth scroll animation, which can snap back to the bottom in headless and does not reproduce a stable scrolled-up viewport.🤖 Generated with Claude Code