[Webkit-unassigned] [Bug 137069] New: iOS8 new "slow tap" heuristic fires mouse compat events despite preventDefault on touchend

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137069

           Summary: iOS8 new "slow tap" heuristic fires mouse compat
                    events despite preventDefault on touchend
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: iOS
               URL: http://patrickhlauke.github.io/touch/tests/event-liste
                    ner_prevent-default-touchend.html
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P2
         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.