Fix #5345: multiline TextArea text/hint jumps vertically when editing starts - #5358
Merged
Merged
Conversation
Themes set a default vertical alignment for text components via the `textCmpVAlignInt` theme constant (commonly CENTER so single-line fields center vertically). That default is applied to every TextArea, including multi-line ones. Commit eefac96 made the lightweight rendering honor that alignment for multi-line text areas, but native editors (on every platform) top-align their content. The result: an editable multi-line TextArea drew its text, cursor and hint centered while idle, then jumped to the top the moment editing started and back down when it ended. Restore the pre-regression behavior only in the rendering path: editable multi-line text areas render top-aligned on platforms whose native editor doesn't support vertical alignment, so the lightweight rendering matches the native editor and nothing shifts. getVerticalAlignment() still returns the logical value that was set, so non-editable multi-line areas keep honoring CENTER/BOTTOM and the existing API contract is preserved. The hint label is aligned the same way so an empty field's hint sits where the cursor will appear instead of floating in the middle. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
Collaborator
Author
|
Compared 144 screenshots: 144 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Contributor
Cloudflare Preview
|
Collaborator
Author
|
Compared 142 screenshots: 142 matched. Benchmark Results
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 143 screenshots: 143 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 216 screenshots: 216 matched. |
The previous commit aligned the hint of every text component to its rendering alignment. For single-line fields that shifted the hint a few pixels (they were not previously centered), which perturbed unrelated TextField hint screenshots (TextFieldTheme, kotlin) on every platform for no functional benefit. Restrict the adjustment to multi-line text areas, which is the only case issue #5345 is about. Single-line fields keep their existing hint behavior, so the device screenshot goldens are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 139 screenshots: 139 matched. |
Collaborator
Author
|
Compared 137 screenshots: 137 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Only reposition the hint when the field actually spans multiple rows (getActualRows() > 1). A one-row growable field such as ChatInput's ChatInputField (a TextField with setSingleLineTextArea(false)) has no vertical gap, so its hint stays centered as before -- this keeps the ChatInput watch screenshots unchanged. On themes that vertically center text (the native iOS and mac themes, via textCmpVAlignInt), an editable multi-line TextArea previously rendered its text centered while idle and jumped to the top when the native editor took over. The fix top-aligns it consistently, so the TextFieldTheme device goldens for iOS (regular + metal) and mac-native are refreshed to the corrected rendering. The Android theme is top-aligned already, so those goldens are unchanged; the watch/tv suites are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replaces the separate getVerticalAlignmentForRendering() with a plain default: an editable multi-line text area reports TOP from getVerticalAlignment() instead of the CENTER theme default, so its lightweight text/cursor/hint line up with the top-aligning native editor and don't jump when editing starts/ends (#5345). Why this is scoped to editable multi-line rather than a blanket field default: the "must be TOP" constraint comes from the native editor, which only exists for editable fields. A blanket default would also top-align every non-editable multi-line area -- notably the TextArea inside every SpanLabel/SpanButton -- changing unrelated rendering. Single-line fields and non-editable areas therefore keep the theme default and still honor CENTER/BOTTOM. An explicit setVerticalAlignment() sets a flag and is always honored, so the value is retained (matching the getter/setter symmetry) even for an editable multi-line area. Rendering and the hint now read getVerticalAlignment() directly; behaviour is identical to the previous commit for every case exercised by a screenshot, so the refreshed iOS/mac goldens stay valid. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The theme's textCmpVAlignInt default is meant for single-line fields; applying it to multi-line areas is what caused the centered-then-jump rendering (#5345). Make every multi-line text area default to TOP -- the original pre-regression behavior -- instead of scoping the fix to editable areas. Non-editable multi-line areas (e.g. the text inside SpanLabel / SpanButton) are top-aligned again too; an explicit setVerticalAlignment() is still honored for display text that wants CENTER/BOTTOM. This drops the isEditable()/supportsNativeTextAreaVerticalAlignment() scoping from getVerticalAlignment(); the earlier version kept those partly to avoid refreshing SpanLabel-based goldens, which was the wrong trade-off. Device goldens that render a non-editable multi-line area with vertical slack are refreshed accordingly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Non-editable multi-line text now top-aligns (SpanLabel/SpanButton captions and body text), so refresh the device goldens on the center-valign themes. Only SpanLabel-based text shifts (a few px, from centered to top); the interactive components and layouts are unchanged. Android keeps its top-aligned theme so its goldens are untouched. Verified each changed category visually (SpanLabelTheme, ButtonTheme, SwitchTheme, ShowcaseTheme, ChatView, DialogTheme, AppReviewDialog). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
Jul 11, 2026
…rk MultiButton The merged tree renders #5358's corrected vertical TextArea/text alignment (shifts every screen with text components, including the measurement-overlay labels on ButtonTheme/SwitchTheme) and the dark MultiButton rounded-rect fix. Verified MultiButtonTheme_ios_dark now renders rounded dark cells; accepted all 16 mac + 30 JS flagged renders. iOS-family (GL/Metal/tv/watch) churn lands with their runs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
Jul 11, 2026
…ty-suite Conflicts resolved by keeping the branch side: - scripts/cn1playground/pom.xml: keep the deliberate 8.0-SNAPSHOT pin (master's 7.0.258 release bump must not touch the playground pin). - 14 scripts/javascript goldens: master's #5361 regenerated them on a tree without this branch's theme changes; ours were captured from the merged tree post-#5358 and remain correct for this PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
shai-almog
added a commit
that referenced
this pull request
Jul 11, 2026
… shift + rounded dark MultiButton GL (16), Metal (16), tv (5), watch (9) renders reviewed against the mac goldens from the merged tree. The old GL/Metal goldens carried pre-#5351 renders where the Metal/GL foreground erase dropped button pills and text-field glass cells (ButtonTheme_dark golden showed bare blue text and H=7mm vs the correct glass pills at H=5mm); the new renders restore them. Remaining churn is the #5358 TextArea vertical alignment shift plus the rounded dark MultiButton fix (74599f4), now confirmed rounded on metal, tv and watch. Deliberately NOT accepted: AnimateLayoutScreenshotTest-family goldens (their committed renders lost the tile text in the final frames on all ParparVM runtimes -- iOS GL/Metal/JS -- while JVM/ART runtimes keep it; that regression is being tracked down separately and the goldens will be refreshed when it is fixed). Co-Authored-By: Claude Fable 5 <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.
Fixes #5345.
Problem
Editing the first field in the reporter's snippet makes the text shift up when editing starts and back down when it ends. With a hint on an empty field, the hint sits vertically centered while the cursor lands on the first line.
Root cause
Themes set a default vertical alignment for text components via the
textCmpVAlignInttheme constant (commonlyCENTER, so single-lineTextFields center their text vertically).LookAndFeelapplies that default to everyTextAreathroughTextArea.setDefaultValign(), so multi-line areas inheritCENTERtoo.Commit
eefac9657a("Align multiline textarea rendering") removed the guard that used to force editable multi-line areas toTOP, so the lightweight rendering started honoringCENTER/BOTTOM. But the native editors (JTextArea / UITextView / EditText / …) top-align their content on every platform (supportsNativeTextAreaVerticalAlignment()isfalseeverywhere). The lightweight render therefore centered the text/cursor/hint while idle and the native editor top-aligned it during editing — hence the jump.Fix
Reinstate the pre-regression behavior, but only in the rendering path via a new
TextArea.getVerticalAlignmentForRendering(): an editable multi-line text area renders top-aligned on platforms whose native editor can't vertically align, so the lightweight rendering matches the native editor and nothing shifts.getVerticalAlignment()still returns the logical value that was set, preserving the API contract and the unit tests added ineefac9657a.CENTER/BOTTOM(the feature that commit intended), so the existingTextAreaAlignmentScreenshotTest/testVerticalAlignmentScreenshotStatesreferences stay valid — they usesetEditable(false).Tests
Added
TextAreaTestcases covering editable multi-line (falls back toTOP), non-editable multi-line (honorsCENTER/BOTTOM), and single-line (honors alignment). FullTextAreaTestsuite: 46/46 green. Core compiles on JDK 8.🤖 Generated with Claude Code