Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
2 participants
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.
Issue number: resolves #30412
What is the current behavior?
When a user listener bound to
ion-inputorion-itemreceives a tap that requires scroll assist to scroll the input into view, the click handler fires twice. ProgrammaticsetFocus()and keyboard focus into an offscreen input also dispatch a phantom click event the developer didn't request.The cause is
scroll-assist.ts: afterrelocateInputmoves the native input, a RAF-scheduledcomponentEl.click()re-emits a click on the host. That recovery was added in #22845 (Feb 2021) to fix #21871, when scroll assist drove focus from its own touchstart/touchend listeners andrelocateInputran during the in-flight click event's lifecycle.What is the new behavior?
The RAF recovery click is removed. #25848 (Sep 2022) restructured scroll assist to react to
focusinrather than drive focus from touch events, sorelocateInputnow runs strictly after the click event has finished propagating. Combined withion-input's click capture handler andion-item's click-on-padding handler from #30373 (April 2025), the click is always dispatched on the component host before scroll assist runs. Re-firing it produced duplicate clicks for user interactions and phantom clicks for programmatic and keyboard focus.Does this introduce a breaking change?
Other information
Regression coverage in
core/src/components/input/test/item/scroll-assist-double-click.e2e.tscovers four cases on iOS Mobile Safari and Mobile Chrome: padding click, direct input click, programmaticsetFocus(), and keyboard focus. The first two assert one click event; the last two assert zero. All four fail without this change and pass with it.Preview: