Fix #1511: TextField.setAlignment(CENTER) is now accepted#5120
Merged
Conversation
Contributor
Cloudflare Preview
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 122 screenshots: 122 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
TextField.setAlignment(int) had thrown IllegalArgumentException for Component.CENTER since the initial commit in 2012. That blocked a common use case the 2015 reporter ran into: a numeric-constraint TextField that needs to be centred for PIN entry / score widgets / calculator-style inputs. There is no technical reason for the restriction -- TextArea.setAlignment already accepts CENTER and the rendering pipeline routes through Style.setAlignment regardless. Drop the IAE and delegate to super.setAlignment. The styling, focus caret rendering and edit-mode native overlays all read the alignment from the Style object exactly the same way they do for LEFT and RIGHT; no special-case code looked at the CENTER value with intent to reject it. Closes #1511. Adds maven/core-unittests/.../TextFieldCenterAlignmentTest.java with: - setAlignmentCenterIsAcceptedOnTextField: the IAE no longer fires, the underlying Style's alignment field is CENTER, and the NUMERIC constraint is preserved. - setAlignmentLeftRightAndCenterAllWork: round-trip through all three cardinal alignments. Full TextField/TextArea sweep (64 tests) stays green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The previous commit on this branch removed the IllegalArgumentException from TextField.setAlignment(CENTER) but left an override whose body was just super.setAlignment(align). PMD's UselessOverridingMethod rule fails the build on that pattern, so CI was red. Delete the override entirely. TextArea.setAlignment now handles every case identically (no LEFT/RIGHT/CENTER asymmetry), so dropping the override gives the exact same behaviour and matches the rest of the TextField API surface that simply inherits its TextArea implementation. Test coverage stays identical via TextFieldCenterAlignmentTest. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
force-pushed
the
fix-1511-textfield-center-alignment
branch
from
5cc73a0 to
dfa077e
Compare
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
1 participant
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.
Summary
Closes #1511. The 2015 reporter wanted a centre-aligned
TextFieldwith aNUMERICconstraint (PIN entry / score widgets / calculator-style inputs).TextField.setAlignment(Component.CENTER)had thrownIllegalArgumentException("CENTER alignment is not supported in TextField.")since the very first commit in 2012, so the reporter had to settle forTextArea(which accepts CENTER but does not enforce the NUMERIC constraint as tightly).There is no technical reason for the restriction:
TextArea.setAlignmentalready accepts CENTER and just routes toStyle.setAlignmentlike every other Component.Dropping the IAE and delegating to
super.setAlignmentlets a numeric-constrained TextField be centred while keeping its constraint, exactly what the reporter asked for.Test plan
TextFieldCenterAlignmentTest:setAlignmentCenterIsAcceptedOnTextField: the IAE no longer fires, the underlyingStyle.getAlignment()is CENTER on both selected and unselected styles, and theNUMERICconstraint is preserved.setAlignmentLeftRightAndCenterAllWork: round-trip through LEFT → CENTER → RIGHT.TextAreaTest, theTextFieldCaretColorTest#2780andTextFieldHintStylingTestregression samples -- stays green.Why I had to fix one test assertion mid-implementation
The first cut of the test asserted on
tf.getAllStyles().getAlignment().Component.getAllStyles()returns a proxy Style whosesetAlignmentfans out to the four sub-styles but does not update the proxy's ownalignfield, so the proxy's getter always returned the original LEFT. Reading fromgetUnselectedStyle().getAlignment()/getSelectedStyle().getAlignment()is the correct round-trip and exposes the real behaviour the test cares about. That's a subtle gotcha worth flagging in the codebase but it is not part of #1511.🤖 Generated with Claude Code