Re: iOS 8's new "slow tap" heuristic

Thanks Patrick!  I confirm I see the same thing.  Apparently I missed this
in my own testing of the beta build (too bad, I know they were eager for
feedback on any issues).

The heuristic is an interesting one.  I wonder how well 150ms discriminates
between taps in practice.  We don't have great data on this, but we do know
that about half of all single-finger gestures on Chrome complete in <150ms
- so that suggests this isn't going to be a big help to addressing the
click delay problem on it's own.

The bug with touchend disposition being ignored is aweful!  The old Android
browser used to ignore touchend dispositions and it was a huge source of
pain.  Hopefully this is something they can fix quickly, it'll be a real
pain to work around (probably exacerbate the problem of sites ignoring
mouse events when touch events are supported).  Please let us know when
you've filed the bug.

Rick


On Wed, Sep 24, 2014 at 5:24 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> 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
>
>