-
Notifications
You must be signed in to change notification settings - Fork 13.5k
feat(input): add input-password-toggle component #29175
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
Conversation
This reverts commit de678b5.
core/src/components/input-password-toggle/input-password-toggle.tsx
Outdated
Show resolved
Hide resolved
core/src/components/input-password-toggle/input-password-toggle.ios.scss
Outdated
Show resolved
Hide resolved
core/src/components/input-password-toggle/input-password-toggle.tsx
Outdated
Show resolved
Hide resolved
core/src/components/input-password-toggle/input-password-toggle.tsx
Outdated
Show resolved
Hide resolved
Issue number: Internal --------- <!-- Please do not submit updates to dependencies unless it fixes an issue. --> <!-- Please try to limit your pull request to one type (bugfix, feature, etc). Submit multiple pull requests if needed. --> ## What is the current behavior? <!-- Please describe the current behavior that you are modifying. --> [Amanda pointed out that the ripple effect for the Button inside of InputPasswordToggle was not working](#29175 (comment)). I found out that calling `ev.preventDefault` on `pointerdown` causes `mouseup` to not get fired. On desktop, we rely on `mouseup` to know when to add the ripple effect. (`touchend` is not impacted) Interestingly, calling `ev.preventDefault` on `pointerdown` does **not** prevent `pointerup` from being fired. The idea here is that if we migrate the tap click utility to use the PointerEvents API instead of separate mouse/touch listeners we can keep the existing tap click behavior while also fixing the bug that Amanda noted. ## What is the new behavior? <!-- Please describe the behavior or changes that are being added by this PR. --> - Tap click nows listens for the Pointer Events instead of separate mouse/touch events Impact to developers is fairly minimal. There should be no behavior change (other than the bug I noted being fixed). There should be a very small perf boost because this util now only adds 4 event listeners on the document instead of 7 previously. ## Does this introduce a breaking change? - [ ] Yes - [x] No <!-- If this introduces a breaking change: 1. Describe the impact and migration path for existing applications below. 2. Update the BREAKING.md file with the breaking change. 3. Add "BREAKING CHANGE: [...]" to the commit description when merging. See https://github.com/ionic-team/ionic-framework/blob/main/.github/CONTRIBUTING.md#footer for more information. --> ## Other information <!-- Any other information that is important to this PR such as screenshots of how the component looks before and after the change. --> Reviewers: Please manually test this on desktop devices as well as iOS and Android devices (not Chrome Dev Tools. iOS simulators are fine). Test that components such as `ion-button` correctly add the activated state (or ripple effect for MD). Also verify that the activated state is not added when tapping the button and then scrolling. For desktop, check that right clicking does not add the activated state.
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.
We discussed the possibility of using the new round button styles in #29161 instead of needing a shadow part to style the new button, but I don't see that as a blocker 👍
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.
This is correct. The team made this screenshot update in next
but it never made its way into feature-8.0
Issue number: Internal
What is the current behavior?
When given a password input it is hard to know what users are typing as the contents of the input are obscured. As a result, it is a common pattern to have a button that lets users temporarily toggle the visibility of the password so they can correct any mistakes. Ionic currently has the infrastructure for developers to implement this on their own, but this use case is so common that the team thinks it is worth having this functionality built-in to Ionic.
What is the new behavior?
ion-input-password-toggle
component. This component is a button that toggles the visibility of the text in the input it is slotted into.Does this introduce a breaking change?
Other information
Docs PR: ionic-team/ionic-docs#3541
Note: We did not do the approach listed in the other PR due to #29141 (comment).