Close #1512: password TextField visibility regression guard#5121
Merged
Conversation
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
…ss (#1512) The 2015 reporter said a TextField with the PASSWORD constraint showed its text correctly while focused, but the text "became invisible" once focus moved to another field. That symptom is no longer reproducible with the current DefaultLookAndFeel render path: getTextFieldString() turns the raw text into the bullet-replaced display string both for the focused and unfocused render paths, and the underlying text is preserved across focus loss. So the bug was apparently fixed implicitly during a later TextField rewrite without the issue being explicitly closed. Add a regression test that: - Builds a Form with a password TextField and an "other" TextField. - Sets some text on the password field while it is focused. - Reflectively calls getTextFieldString() to capture the focused display string and verifies every character is replaced with a non-space bullet glyph. - Moves focus to the other field, asserts password.getText() still returns the underlying text, and asserts the unfocused display string is byte-identical to the focused one. The 2015 bug, if it ever returns, would either drop characters from this string or return an all-spaces string -- either is caught here. Closes #1512 (as "already fixed, locked in by test"). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
shai-almog
force-pushed
the
investigate-1512-password-textfield-focus
branch
from
75c013c to
fd41b6d
Compare
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 #1512 as already fixed, with the test as the lock-in.
The 2015 reporter wrote that a
TextFieldwith thePASSWORDconstraint showed its text correctly while focused but the text "became invisible" once focus moved to another field. I could not reproduce that symptom with the currentDefaultLookAndFeelrender path:getTextFieldString()builds the bullet-replaced display string identically for the focused and unfocused paths, and the underlying text is preserved across focus loss. The bug was apparently fixed implicitly during a later TextField rewrite and the issue was never closed.What the test guards against
The new
PasswordTextFieldVisibilityTest:TextFieldand a second"Other"TextField."secret123"on the password field while it is focused.DefaultLookAndFeel.getTextFieldString(TextArea)to capture the focused display string and asserts:password.getText()still returns"secret123"(the underlying data isn't cleared)If the 2015 bug ever returns -- whether by clearing the displayed string, replacing it with spaces, dropping characters, or routing through a focus-conditional branch that returns empty -- this test fails loudly.
Test plan
master(proving the bug is no longer present).🤖 Generated with Claude Code