Summary: | iOS8 new "slow tap" heuristic fires mouse compat events despite preventDefault on touchend | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Patrick H. Lauke <redux> | ||||
Component: | UI Events | Assignee: | Benjamin Poulain <benjamin> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | benjamin, dbates, ddkilzer, mmfrezabakhshi, rbyers, rkerr, rowan, sabouhallawa, sam, simon.fraser | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | iPhone / iPad | ||||||
OS: | Other | ||||||
URL: | http://patrickhlauke.github.io/touch/tests/event-listener_prevent-default-touchend.html | ||||||
Attachments: |
|
Description
Patrick H. Lauke
2014-09-24 10:55:59 PDT
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 Damn :( Adding this to my "touch TODO list". 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. (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. Ah thanks, so the "long tap suppresses click delay" behavior isn't intentional either then? (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. > (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.
Created attachment 240453 [details]
Patch
Comment on attachment 240453 [details] 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 Committed r176305: <http://trac.webkit.org/changeset/176305> |