-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
fix: bug 17965 #22479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix: bug 17965 #22479
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
| ) { | ||
| this.expectingCharAfterClear = true; | ||
| return { password: prevState.password }; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: iOS Password Field: Unclearable
The workaround for the iOS secure text entry bug prevents users from intentionally clearing the password field. When a user focuses the field and manually selects all text and deletes it, the condition prevState.password === this.passwordAtFocusTime is true, causing the workaround to incorrectly preserve the old password instead of allowing the deletion. The logic cannot distinguish between iOS sending a spurious empty string and the user intentionally clearing the field.
|
|
||
| this.expectingCharAfterClear = false; | ||
| return { password: val }; | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Visibility Toggle Erases Secure Passwords
When the iOS secure text entry workaround is active (expectingCharAfterClear is true) and the user toggles password visibility before the next character arrives, the original password is lost. The second condition checks isSecureTextEntry, so after toggling visibility it falls through to the default case which sets password to just the new value, discarding passwordAtFocusTime. The same issue exists in setConfirmPassword for the confirm password field.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #22479 +/- ##
==========================================
- Coverage 77.91% 77.90% -0.02%
==========================================
Files 3836 3836
Lines 98091 98221 +130
Branches 19259 19282 +23
==========================================
+ Hits 76430 76521 +91
- Misses 16413 16469 +56
+ Partials 5248 5231 -17 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|



Description
BugFix: #17965 (Typing in the input field after it was unfocused and focused leads to the entire password getting deleted and replaced)
Jira: https://consensyssoftware.atlassian.net/browse/SL-282
Changelog
CHANGELOG entry: BugFix: #17965
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Screen.Recording.2025-11-11.at.6.51.29.PM.mov
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Harden password and confirm input handling to avoid full deletion/incorrect replacement on refocus, clear confirm when password is cleared, and disable select-on-focus.
password/confirmPasswordfrom being wiped when refocusing secure fields and to correctly append characters after accidental clears.confirmPasswordwhenpasswordbecomes empty (incomponentDidUpdateand on blur).onFocus/onBlurto bothTextFields; setselectTextOnFocus={false}for each.selectTextOnFocus={false}prop.Written by Cursor Bugbot for commit c4783c6. Configure here.