Repository navigation
Simulator: draw the native editor where the panned field is - #6133
Merged
Merged
Conversation
In the simulated keyboard's Android pan mode the native editor's bounds are raised by the pan offset, and the screen raster it is painted into is raised by the same offset again when it is composed, so typed text appeared one pan offset above the field, over unrelated content. Paint the editor lowered by the offset into the raster and clip it out of the regular children pass; its bounds, and so its hit area, stay where the field is drawn. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The editor's bounds are recomputed only when it repaints, so the frame after the keyboard opened, after Next moved to another field or after the keyboard hid drew it from bounds made for the previous offset. Raise the initial bounds by the offset too, and repaint the editor whenever the offset changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks: |
Collaborator
Author
|
Compared 12 screenshots: 12 matched. |
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
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
With the simulated keyboard in Android pan mode (forced, or chosen by
autofor a field low on the screen), the text being typed was drawn one pan offset above the field, over whatever content sat there, while the field itself looked empty. iOS mode and Android resize mode were unaffected.The native Swing editor's bounds are raised by the pan offset (
RepainterineditStringOnAwtThread), so it sits, and takes clicks, where the panned field is drawn rather than under the keyboard. But the editor is painted into the screen raster, andcomposeSimulatorOverlaysraises that whole raster by the same offset again. The editor moved twice.Fix
C.paintChildrenIntoBufferpaints the editor lowered by the pan offset and clips it out of the regular children pass. Its bounds, and so its hit area, are unchanged.editStringnow subtract the pan offset asRepainterdoes, andsetPanOffsetrepaints the editor so its bounds are recomputed on every offset change (keyboard opening, Next to another field, keyboard hiding). Without that, the frame after a change drew the editor from bounds made for the previous offset; an adversarial review of the first commit found this.Secondary window canvases are untouched (
this == canvas); a stale editor is ignored (getParent() != this).Verification
A sign up form with the email and password fields low on a Pixel skin, driven over the simulator's MCP (
sim_keyboard_set,sim_tap,sim_keyboard_type,sim_keyboard_key) and recorded withsim_record_*:Checked at one zoom level only. The compose step scales the pan by
buffer width / screen widthand this paint byzoomLevel, the same assumption the existing bounds code makes; at most about a pixel of rounding differs.🤖 Generated with Claude Code