Skip to content
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

iOS events captured twice #47

Closed
erpheus opened this issue May 5, 2020 · 2 comments · Fixed by #82
Closed

iOS events captured twice #47

erpheus opened this issue May 5, 2020 · 2 comments · Fixed by #82

Comments

@erpheus
Copy link

erpheus commented May 5, 2020

If using an iOS device (tested on safari iOS 13 on iPhone and iPad) a simple tap to choose an hour will also select the minute with the closest placement.

This behavior is not so bad if the picker does not close itself, but I built one with the option closeOnMinuteSelect enabled and what happens is that with one tap both get selected and the picker closes. Thus the only choosable times are 12:00, 1:05, 6:30, etc...

This does not happen if instead of tapping the finger is held, dragged around and released.

I inspected the events firing in mobile safari and it seems like there are both touch and click events going on. My guess is that there is a preventdefault call missing in the touchstart or touchdown events, that would tell iOS not to generate a click one as well, but I'm not sure. I haven't tested it deeply.

Here is a screencast showing the problem. I'm only clicking on the hours and you can see the seconds immediately change (then I click on the hour number at the top to try again).

ezgif-7-d15e82cd09f8

@catc
Copy link
Owner

catc commented May 13, 2020

Thanks for reporting the bug. Unfortunately I don't have an ios device to test a fix but if you open a PR I can review it.

Adding the help wanted label for the time being.

@erpheus
Copy link
Author

erpheus commented May 16, 2020

Today I forked the project and added some logs to try to understand the issue with the touch and click events. This is the "typical" flow of events on desktop (true in 'send change' corresponds to canAutoChangeUnit in calculatePoint):

image

And this the one on my iPhone:

image

Which suggest something needs to be done in the touch handlers to let safari know that it should not trigger the click ones as well. But I wonder, doesn't this happen on android browsers too? Or do they determine whether a website has properly reacted to a touch event (to maybe send a click one) in a different way?

@catc catc closed this as completed in #82 Jan 3, 2022
catc added a commit that referenced this issue Jan 3, 2022
* fix #47 

* memoize event listener functions, fix cleanup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants