137069 2014-09-24 10:55:59 -0700 iOS8 new "slow tap" heuristic fires mouse compat events despite preventDefault on touchend 2014-11-18 21:06:47 -0800 1 1 1 Unclassified WebKit UI Events 528+ (Nightly build) iPhone / iPad Other RESOLVED FIXED http://patrickhlauke.github.io/touch/tests/event-listener_prevent-default-touchend.html InRadar P2 Normal --- 1 redux benjamin benjamin dbates ddkilzer mmfrezabakhshi rbyers rkerr rowan sabouhallawa sam simon.fraser oldest_to_newest 1036989 0 redux 2014-09-24 10:55:59 -0700 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?) 1036998 1 rbyers 2014-09-24 12:04:04 -0700 Yeah it seems really unfortunate that safari sends click events in this case even though touchend has been consumed. Old versions of the android browser behaved like that and it was a huge source of pain for web developers - forcing them to do unnatural things like trying to "bust ghost clicks": https://developers.google.com/mobile/articles/fast_buttons#ghost 1037009 2 benjamin 2014-09-24 12:43:40 -0700 Damn :( Adding this to my "touch TODO list". 1037018 3 rbyers 2014-09-24 13:36:00 -0700 Thanks Benjamin! Sorry I didn't spot this in my experimentation with the earlier beta. I definitely played with touch consumption modes (http://www.rbyers.net/eventTest.html), but it never occurred to me that tap duration was at all relevant to the behavior. Will you guys be discussing the behavior / reasoning here around tap duration at some point? It's certainly an interesting idea. 1037024 4 benjamin 2014-09-24 14:24:57 -0700 (In reply to comment #3) > Thanks Benjamin! Sorry I didn't spot this in my experimentation with the earlier beta. I definitely played with touch consumption modes (http://www.rbyers.net/eventTest.html), but it never occurred to me that tap duration was at all relevant to the behavior. I did test this case as well and I did not catch the bug. The problem is related to the gesture recognizers installed in the app, it is very possible we have all tested a working version and something else changed in the system that broke this later. :( > Will you guys be discussing the behavior / reasoning here around tap duration at some point? It's certainly an interesting idea. I changed the dependency graph of the long press. Another example is that you can now pinch to zoom after the tap highlight is shown, this was impossible before. 1037027 5 rbyers 2014-09-24 14:28:11 -0700 Ah thanks, so the "long tap suppresses click delay" behavior isn't intentional either then? 1037030 6 benjamin 2014-09-24 14:47:04 -0700 (In reply to comment #5) > Ah thanks, so the "long tap suppresses click delay" behavior isn't intentional either then? It is. It is the byproduct of relaxed constraints on the graph. We don't add delays explicitly, they happen because other gesture recognizers (e.g. double tap) add a restriction. I am not saying long press will always works this way. A new system gesture could redefine how we have to handle the graph. But at the moment, this is something we can do. 1037032 7 rbyers 2014-09-24 14:51:28 -0700 > (In reply to comment #5) > > Ah thanks, so the "long tap suppresses click delay" behavior isn't intentional either then? > > It is. It is the byproduct of relaxed constraints on the graph. We don't add delays explicitly, they happen because other gesture recognizers (e.g. double tap) add a restriction. Ah, right - we don't have the nice UIGestureRecognizer-style abstraction system you do. Makes sense, thanks. 1044124 8 240453 benjamin 2014-10-24 21:35:42 -0700 Created attachment 240453 Patch 1044159 9 ddkilzer 2014-10-25 20:31:57 -0700 <rdar://problem/18481464> 1049594 10 240453 simon.fraser 2014-11-18 14:25:41 -0800 Comment on attachment 240453 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=240453&action=review > Source/WebKit2/ChangeLog:15 > + run concurrently. This causes a race with an incorrect behavior: > + -If UIWebTouchEventsGestureRecognizer does not cancel the native gestures on start. > + -_UIWebHighlightLongPressGestureRecognizer starts after highlightDelay. > + -When the finger leaves the screen, both gestures end. > + -> If the touch end sent to JavaScript ask the priority over native events, that no longer stops > + the _UIWebHighlightLongPressGestureRecognizer. The formatting here makes it hard for me to follow the logic of the explanation. > Source/WebKit2/ChangeLog:19 > + if the page want the event. wants > Source/WebKit2/ChangeLog:29 > + the gesture can end normally. This is done on timer and not direct input so I don't really have to worry on a timer 1049706 11 benjamin 2014-11-18 21:06:47 -0800 Committed r176305: <http://trac.webkit.org/changeset/176305> 240453 2014-10-24 21:35:42 -0700 2014-11-18 14:25:41 -0800 Patch bug-137069-20141024213549.patch text/plain 5283 benjamin U3VidmVyc2lvbiBSZXZpc2lvbjogMTc1MTk2CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggM2U2NjdlNmJjZmZmM2Zh ODAyYWIwMGQwMDdhMzRmZWIwMmQ3ZDc5NC4uNWQxYjkyODhjNmJiNTE1OTZmZTAzNDgyYmM0MmIw N2VkZjdmNzk3OSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSw1ICsxLDQ1IEBACiAyMDE0LTEwLTI0ICBCZW5q YW1pbiBQb3VsYWluICA8YnBvdWxhaW5AYXBwbGUuY29tPgogCisgICAgICAgIGlPUzggbmV3ICJz bG93IHRhcCIgaGV1cmlzdGljIGZpcmVzIG1vdXNlIGNvbXBhdCBldmVudHMgZGVzcGl0ZSBwcmV2 ZW50RGVmYXVsdCBvbiB0b3VjaGVuZAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9z aG93X2J1Zy5jZ2k/aWQ9MTM3MDY5CisgICAgICAgIHJkYXI6Ly9wcm9ibGVtLzE4NDgxNDY0CisK KyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgT24gV2ViS2l0 Miwgd2UgbGV0IFVJV2ViVG91Y2hFdmVudHNHZXN0dXJlUmVjb2duaXplciBhbmQgX1VJV2ViSGln aGxpZ2h0TG9uZ1ByZXNzR2VzdHVyZVJlY29nbml6ZXIKKyAgICAgICAgcnVuIGNvbmN1cnJlbnRs eS4gVGhpcyBjYXVzZXMgYSByYWNlIHdpdGggYW4gaW5jb3JyZWN0IGJlaGF2aW9yOgorICAgICAg ICAtSWYgVUlXZWJUb3VjaEV2ZW50c0dlc3R1cmVSZWNvZ25pemVyIGRvZXMgbm90IGNhbmNlbCB0 aGUgbmF0aXZlIGdlc3R1cmVzIG9uIHN0YXJ0LgorICAgICAgICAtX1VJV2ViSGlnaGxpZ2h0TG9u Z1ByZXNzR2VzdHVyZVJlY29nbml6ZXIgc3RhcnRzIGFmdGVyIGhpZ2hsaWdodERlbGF5LgorICAg ICAgICAtV2hlbiB0aGUgZmluZ2VyIGxlYXZlcyB0aGUgc2NyZWVuLCBib3RoIGdlc3R1cmVzIGVu ZC4KKyAgICAgICAgLT4gSWYgdGhlIHRvdWNoIGVuZCBzZW50IHRvIEphdmFTY3JpcHQgYXNrIHRo ZSBwcmlvcml0eSBvdmVyIG5hdGl2ZSBldmVudHMsIHRoYXQgbm8gbG9uZ2VyIHN0b3BzCisgICAg ICAgICAgIHRoZSBfVUlXZWJIaWdobGlnaHRMb25nUHJlc3NHZXN0dXJlUmVjb2duaXplci4KKwor ICAgICAgICBUaGUgdHdvIGdlc3R1cmUgcmVjb2duaXplcnMgY2FuIHJ1biBpbiBhbnkgb3JkZXIs IHRoZXJlIGlzIG5vIGd1YXJhbnRlZSBvbiB3aGljaCBvbmUgcnVucyBmaXJzdC4KKyAgICAgICAg VG8gc29sdmUgdGhlIGJ1ZywgSSBtdXN0IG1ha2Ugc3VyZSB0aGUgX1VJV2ViSGlnaGxpZ2h0TG9u Z1ByZXNzR2VzdHVyZVJlY29nbml6ZXIgbmV2ZXIgdHJpZ2dlciBhIGNsaWNrCisgICAgICAgIGlm IHRoZSBwYWdlIHdhbnQgdGhlIGV2ZW50LgorCisgICAgICAgIFRvIHNvbHZlIHRoZSBvcmRlciBw cm9ibGVtLCBJIHVzZSB0aGUgZmFjdCB0aGF0IGV2ZW50IHJlY29nbml0aW9uIGdvZXMgaW4gdHdv IHBoYXNlcyBmb3IKKyAgICAgICAgbm9uIGNhbmNlbGxlZCBldmVudHM6CisgICAgICAgIDEpIFVw ZGF0ZSB0aGUgZ2VzdHVyZSByZWNvZ25pemVycy4KKyAgICAgICAgMikgVHJpZ2dlciB0aGUgYWN0 aW9ucy4KKworICAgICAgICBJIGRvIG5vdCBrbm93IHRoZSBvcmRlciBvZiByZWNvZ25pemVycyBp biBbMV0sIGJ1dCBJIGtub3cgYm90aCBoYXZlIHJ1biBiZWZvcmUgWzJdIGlzIGV4ZWN1dGVkLgor ICAgICAgICBJIHVzZSB0aGF0IHRvIHN0b3AgX1VJV2ViSGlnaGxpZ2h0TG9uZ1ByZXNzR2VzdHVy ZVJlY29nbml6ZXIgZnJvbSBlbmRpbmcgd2l0aCBhIGNsaWNrIGluIHRoZSBjYXNlIG9mIHRoZSBi dWc6CisgICAgICAgIDEpIFdoZW4gX1VJV2ViSGlnaGxpZ2h0TG9uZ1ByZXNzR2VzdHVyZVJlY29n bml6ZXIgc3RhcnRzLCBJIHNldCBfaGlnaGxpZ2h0TG9uZ1ByZXNzQ2FuQ2xpY2sgc2lnbmFsaW5n CisgICAgICAgICAgIHRoZSBnZXN0dXJlIGNhbiBlbmQgbm9ybWFsbHkuIFRoaXMgaXMgZG9uZSBv biB0aW1lciBhbmQgbm90IGRpcmVjdCBpbnB1dCBzbyBJIGRvbid0IHJlYWxseSBoYXZlIHRvIHdv cnJ5CisgICAgICAgICAgIGFib3V0IGEgcmFjZSBoZXJlLgorICAgICAgICAyKSBXaGVuIHByb2Nl c3NpbmcgdGhlIHRvdWNoIGV2ZW50IGZvciBVSVdlYlRvdWNoRXZlbnRzR2VzdHVyZVJlY29nbml6 ZXIsIEkgcmVzZXQgdGhlIGZsYWcgX2hpZ2hsaWdodExvbmdQcmVzc0NhbkNsaWNrCisgICAgICAg ICAgIGlmIHRoZSBwYWdlIHdhbnRzIHRoZSBldmVudC4KKyAgICAgICAgMykgV2hlbiB0aGUgYWN0 aW9ucyBvZiBfVUlXZWJIaWdobGlnaHRMb25nUHJlc3NHZXN0dXJlUmVjb2duaXplciBhcmUgcHJv Y2Vzc2VkLCB0aGUgdG91Y2ggZXZlbnQKKyAgICAgICAgICAgaGFzIGFscmVhZHkgYmVlbiBwcm9j ZXNzZWQgYnkgdGhlIHBhZ2UgYW5kIHRoZSBmbGFnIGhhcyBiZWVuIGNsZWFyZWQgaWYgbmVlZGVk LgorCisgICAgICAgICogVUlQcm9jZXNzL2lvcy9XS0NvbnRlbnRWaWV3SW50ZXJhY3Rpb24uaDoK KyAgICAgICAgKiBVSVByb2Nlc3MvaW9zL1dLQ29udGVudFZpZXdJbnRlcmFjdGlvbi5tbToKKyAg ICAgICAgKC1bV0tDb250ZW50VmlldyBfd2ViVG91Y2hFdmVudDpwcmV2ZW50c05hdGl2ZUdlc3R1 cmVzOl0pOgorICAgICAgICAoLVtXS0NvbnRlbnRWaWV3IF9oaWdobGlnaHRMb25nUHJlc3NSZWNv Z25pemVkOl0pOgorCisyMDE0LTEwLTI0ICBCZW5qYW1pbiBQb3VsYWluICA8YnBvdWxhaW5AYXBw bGUuY29tPgorCiAgICAgICAgIEZpeCB0aGUgaU9TIGJ1aWxkCiAKICAgICAgICAgKiBDb25maWd1 cmF0aW9ucy9XZWJLaXQueGNjb25maWc6CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9VSVBy b2Nlc3MvaW9zL1dLQ29udGVudFZpZXdJbnRlcmFjdGlvbi5oIGIvU291cmNlL1dlYktpdDIvVUlQ cm9jZXNzL2lvcy9XS0NvbnRlbnRWaWV3SW50ZXJhY3Rpb24uaAppbmRleCA5MzNhMDQ1OGIwZWYy NzE5MWY2MDE0ZDRiNTRlMGQ2ZDgyMDkyM2ZhLi5hMDY2ZTcyNjU3YTZhZjM5MGY3MzI1YzYzOGY5 MzE2ZWVlMzM4ZjA3IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvaW9zL1dL Q29udGVudFZpZXdJbnRlcmFjdGlvbi5oCisrKyBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9p b3MvV0tDb250ZW50Vmlld0ludGVyYWN0aW9uLmgKQEAgLTEzNiw2ICsxMzYsNyBAQCBzdHJ1Y3Qg V0tBdXRvQ29ycmVjdGlvbkRhdGEgewogICAgIEJPT0wgX2hhc1ZhbGlkUG9zaXRpb25JbmZvcm1h dGlvbjsKICAgICBCT09MIF9pc1RhcEhpZ2hsaWdodElEVmFsaWQ7CiAgICAgQk9PTCBfcG90ZW50 aWFsVGFwSW5Qcm9ncmVzczsKKyAgICBCT09MIF9oaWdobGlnaHRMb25nUHJlc3NDYW5DbGljazsK ICAgICBCT09MIF9oYXNUYXBIaWdobGlnaHRGb3JQb3RlbnRpYWxUYXA7CiAgICAgQk9PTCBfc2Vs ZWN0aW9uTmVlZHNVcGRhdGU7CiAgICAgQk9PTCBfc2hvdWxkUmVzdG9yZVNlbGVjdGlvbjsKZGlm ZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9pb3MvV0tDb250ZW50Vmlld0ludGVy YWN0aW9uLm1tIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL2lvcy9XS0NvbnRlbnRWaWV3SW50 ZXJhY3Rpb24ubW0KaW5kZXggNTMzMzMzOGRhNjVmMTZiYWQ0NGYzYmI1NzY5OThmOTQ4MTVlMTIx Mi4uZDUzOTVjYmI3MGJiYzkzOGU1NWQxMTcyZjVkMGE3M2FjYzhhOGFiYiAxMDA2NDQKLS0tIGEv U291cmNlL1dlYktpdDIvVUlQcm9jZXNzL2lvcy9XS0NvbnRlbnRWaWV3SW50ZXJhY3Rpb24ubW0K KysrIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL2lvcy9XS0NvbnRlbnRWaWV3SW50ZXJhY3Rp b24ubW0KQEAgLTUzNyw2ICs1MzcsOCBAQCBzdGF0aWMgRmxvYXRRdWFkIGluZmxhdGVRdWFkKGNv bnN0IEZsb2F0UXVhZCYgcXVhZCwgZmxvYXQgaW5mbGF0ZVNpemUpCiAtICh2b2lkKV93ZWJUb3Vj aEV2ZW50Oihjb25zdCBXZWJLaXQ6Ok5hdGl2ZVdlYlRvdWNoRXZlbnQmKXRvdWNoRXZlbnQgcHJl dmVudHNOYXRpdmVHZXN0dXJlczooQk9PTClwcmV2ZW50c05hdGl2ZUdlc3R1cmUKIHsKICAgICBp ZiAocHJldmVudHNOYXRpdmVHZXN0dXJlKSB7CisgICAgICAgIF9oaWdobGlnaHRMb25nUHJlc3ND YW5DbGljayA9IE5POworCiAgICAgICAgIF9jYW5TZW5kVG91Y2hFdmVudHNBc3luY2hyb25vdXNs eSA9IFlFUzsKICAgICAgICAgW190b3VjaEV2ZW50R2VzdHVyZVJlY29nbml6ZXIgc2V0RGVmYXVs dFByZXZlbnRlZDpZRVNdOwogICAgIH0KQEAgLTkzNCwxOSArOTM2LDIyIEBAIHN0YXRpYyBpbmxp bmUgYm9vbCBpc1NhbWVQYWlyKFVJR2VzdHVyZVJlY29nbml6ZXIgKmEsIFVJR2VzdHVyZVJlY29n bml6ZXIgKmIsIFVJCiAKICAgICBzd2l0Y2ggKFtnZXN0dXJlUmVjb2duaXplciBzdGF0ZV0pIHsK ICAgICBjYXNlIFVJR2VzdHVyZVJlY29nbml6ZXJTdGF0ZUJlZ2FuOgorICAgICAgICBfaGlnaGxp Z2h0TG9uZ1ByZXNzQ2FuQ2xpY2sgPSBZRVM7CiAgICAgICAgIGNhbmNlbFBvdGVudGlhbFRhcElm TmVjZXNzYXJ5KHNlbGYpOwogICAgICAgICBfcGFnZS0+dGFwSGlnaGxpZ2h0QXRQb3NpdGlvbihb Z2VzdHVyZVJlY29nbml6ZXIgc3RhcnRQb2ludF0sICsrX2xhdGVzdFRhcEhpZ2hsaWdodElEKTsK ICAgICAgICAgX2lzVGFwSGlnaGxpZ2h0SURWYWxpZCA9IFlFUzsKICAgICAgICAgYnJlYWs7CiAg ICAgY2FzZSBVSUdlc3R1cmVSZWNvZ25pemVyU3RhdGVFbmRlZDoKLSAgICAgICAgaWYgKCFfcG9z aXRpb25JbmZvcm1hdGlvbi5jbGlja2FibGVFbGVtZW50TmFtZS5pc0VtcHR5KCkpIHsKKyAgICAg ICAgaWYgKF9oaWdobGlnaHRMb25nUHJlc3NDYW5DbGljayAmJiAhX3Bvc2l0aW9uSW5mb3JtYXRp b24uY2xpY2thYmxlRWxlbWVudE5hbWUuaXNFbXB0eSgpKSB7CiAgICAgICAgICAgICBbc2VsZiBf YXR0ZW1wdENsaWNrQXRMb2NhdGlvbjpbZ2VzdHVyZVJlY29nbml6ZXIgc3RhcnRQb2ludF1dOwog ICAgICAgICAgICAgW3NlbGYgX2ZpbmlzaEludGVyYWN0aW9uXTsKICAgICAgICAgfSBlbHNlCiAg ICAgICAgICAgICBbc2VsZiBfY2FuY2VsSW50ZXJhY3Rpb25dOworICAgICAgICBfaGlnaGxpZ2h0 TG9uZ1ByZXNzQ2FuQ2xpY2sgPSBOTzsKICAgICAgICAgYnJlYWs7CiAgICAgY2FzZSBVSUdlc3R1 cmVSZWNvZ25pemVyU3RhdGVDYW5jZWxsZWQ6CiAgICAgICAgIFtzZWxmIF9jYW5jZWxJbnRlcmFj dGlvbl07CisgICAgICAgIF9oaWdobGlnaHRMb25nUHJlc3NDYW5DbGljayA9IE5POwogICAgICAg ICBicmVhazsKICAgICBkZWZhdWx0OgogICAgICAgICBicmVhazsK