- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 24 Sep 2014 10:24:24 +0100
- To: "public-touchevents@w3.org" <public-touchevents@w3.org>
- CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Hey all, just a quick heads-up on some weird new heuristic behavior that I've encountered in iOS 8 / Safari (and the new WKWebView, but NOT the old UIWebView) concerning touch events. I came across this while doing a bit of documentation on approaches to remove the 300ms delay [1] It seems Apple implemented a "slow tap" heuristic, which distinguishes between a quick tap (where the time difference between touchstart and touchend is < 125ms or thereabouts) and a "slow tap" (where the time delta is > 125ms). [2] Quick taps behave the same as before in iOS 7 - they cause the classic 300ms delay after touchend and before mouse compatibility + click events are fire. Nothing new here. Slow taps, however, optimise away the 300ms delay - mouse compatibility + click events are fired instantly after touchend. [3] More bizarrely, though, slow taps now also fire mouse compatibility + click events when touchend has been cancelled (e.g. with preventDefault). [4] [5] This seems to be a bug, rather than a feature - suspect this is an unforeseen consequence of this heuristic behavior, as I can't come up with any good reason why this should be so. I'll be filing a bug on WebKit and see if we can get some clarification on this... [1] http://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay [2] https://github.com/ftlabs/fastclick/issues/262#issuecomment-56363076 [3] https://www.youtube.com/watch?v=k-UiuPp2CK0 [4] https://github.com/ftlabs/fastclick/issues/262#issuecomment-56642232 [5] https://www.youtube.com/watch?v=i787lZCL_YQ P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 24 September 2014 09:24:42 UTC