[Webkit-unassigned] [Bug 137069] New: iOS8 new "slow tap" heuristic fires mouse compat events despite preventDefault on touchend
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Sep 24 10:55:59 PDT 2014
Summary: iOS8 new "slow tap" heuristic fires mouse compat
events despite preventDefault on touchend
Version: 528+ (Nightly build)
Component: Event Handling
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: redux at splintered.co.uk
CC: benjamin at webkit.org
It appears that iOS8/Safari (and the new WKWebView) implements some form of "slow tap" heuristic in an attempt to work around the classic 300ms delay that normally happens between touchend and the mouse compatibility + click events (which other browsers have worked around more explicitly by supporting things like taking hints from viewport https://bugs.webkit.org/show_bug.cgi?id=122212 or taking a hint from touch-action https://bugs.webkit.org/show_bug.cgi?id=133112).
Quick taps behave as they did before in iOS7, meaning that tapping on a button would generate a sequence of touchstart > [touchmove]+ > touchend > [300ms delay] > mouseover > mouseenter > mousemove > mousedown > mouseup > click
However, "slow" taps (where the time between touchstart and touchend is above approximately 125ms) seem to magically optimise the 300ms away - see https://www.youtube.com/watch?v=k-UiuPp2CK0 - which is an interesting approach (just shame that this doesn't appear to be documented anywhere, and has not been communicated to developers, who are already finding mysterious bugs in their existing code because of it, such as https://github.com/ftlabs/fastclick/issues/262)
In general, I can understand the rationale here: a quick tap is more likely to be part of a double-tap sequence, hence the 300ms delay is necessary as before to wait for a possible second tap, while a slower tap is more likely to be an explicit "activation" intent on part of the user.
It seems, though, that this heuristic also has some unintended side effects (or at least, I can't rationalise why Safari would be doing this): traditionally, cancelling the touchend event (e.g. with preventDefault) would suppress any further mouse compatibility events and click from being fired - see iOS7 https://www.youtube.com/watch?v=HmXvwYcFkps. But the new heuristic in iOS8 seems to kick in here as well: "slow" taps, even when touchend has been preventDefault-ed, now fire mouse compatibility and click - see https://www.youtube.com/watch?v=i787lZCL_YQ
Could I get confirmation please if the above heuristic assessment is correct in principle (that the threshold between touchstart and touchend that determines whether it's a quick or slow tap is roughly 125ms), and more importantly if the second behavior - that despite touchend being cancelled the mouse compatibility and click events are being fired - is a bug or a feature (and, if the latter, maybe an indication of the rationale behind it?)
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned