onTouchTap triggering handler twice

[piranha]

We're using TapEventPlugin in our application and it calls every handler twice. Those calls are triggered by different events - first time by touchend, and second time by mouseup, which is generated by a browser as a click. This doesn't make any sense, so I think TapEventPlugin should prevent triggering by a mouseup when event was triggered by touches.

Not sure if there is a good way. I guess calling e.preventDefault() inside of TapEventPlugin is not the wisest solution, is it?

[syranide]

It's arguable for e.preventDefault() to be called by TapEventPlugin if a handler is defined, but it's not always what you want and there would be no way of "undoing" it, I don't see a way around that.

Since what's really going on here is the browser trying to play nice by emulating mouse events for touch, a way to selectively disable emulation is an idea. But node-wise sounds kind of useless (and becomes yet another reserved non-standard attribute) and I'm not sure how you would do it "owner component"-wise, it would probably introduce additional issues for when components are supplied as children to another component.

PS. You can currently return false instead I think, but that's about to be deprecated it seems, so don't do it. :)

[piranha]

Yeah, I can return false, but that's more or less the same as calling .preventDefault(). What if I don't want to prevent an event? Should I get two calls of the same handler?

[syranide]

It seems this is a wide-spread issue, some quick googling reveals that a lot of people seem quite confused about what to do, didn't find any useful answer during my quick search. Additionally, it doesn't seem to be preventDefaultable in IE10 if "some guy is right".

[piranha]

Ok, so I fixed it for myself the hard way - if taps are enabled then don't react to clicks.

And I check for taps like that:

  React.initializeTouchEvents(('ontouchstart' in window) ||
         window.DocumentTouch && document instanceof DocumentTouch);

That of course rules out laptops with touch screens, and is not working very good on IE10, but I can live with it for now.

[syranide]

@piranha It also means you have to support touchevents for all components, you cannot fallback in places you don't care.

[piranha]

Yeah, we're doing onTap={...} everywhere.

[s0meone]

@piranha, I believe your solution isn't ideal.

First off, the touch detection you're using gives false positives (including my current version of Chrome, 36.0.1985.143. 'ontouchstart' in window does return true, but ontouchstart never gets triggered.) And since you're either listening for mouse or touch events based on this feature detection, your tap handler never gets fired.
See modernizr's source for more info about this.

Second, I'm not sure about the environment you're working with, but you're either listening for mouse or touch events. But how about devices that support both?

When trying to fix this problem, we also tried to return false and preventDefault but this failed. Because we change the state after a touch and render an extra element to the DOM that overlays the tap area, all following mouse events are triggered on the overlayed element, and not on the same element the touch handlers had been fired on.

The solution we came up with is to ignore all mouse events within 750ms of the last touch event. Since all emulated mouse events are triggered directly after the touch events, we can easily ignore these. We chose 750ms because it's a reasonable amount of time to be considered as the same user interaction.

With this solution the tap handler is always invoked once per user interaction. It also never excludes events, so the user is allowed to use both their finger and mouse.

Our solution: zilverline/react-tap-event-plugin@zilverline:v0.11.0...patch-tap-event

[syranide]

@s0meone Hmm, regarding 750ms, are there actually emulated mouse events that fire delayed from the touch action/does not have a touch action? I would assume that a delay of "0" would be enough (if it happens immediately it's from the touch event, else it's from a mouse).

[piranha]

Wow, that's certainly much better, I just needed a really quick fix and couldn't come up with better idea. Your patch seems a good one, though I think it makes sense decreasing threshold to, say, 350ms. IIRC 300ms is a delay between a tap and an emulated click event.

[s0meone]

Well, you'd hope the emulated mouse events would be fired immediately after the touch events but they aren't. We've had delays up to ~450ms.

Logs from the iOS Simulator:

---

[Log] touch event topTouchStart 1409061289113 (react-with-addons.js, line 16870)
[Log] touch event topTouchEnd 1409061289183 (react-with-addons.js, line 16870)
[Log] non touch event topMouseMove time diff 363 (react-with-addons.js, line 16872)
[Log] non touch event topMouseDown time diff 365 (react-with-addons.js, line 16872)
[Log] non touch event topMouseUp time diff 366 (react-with-addons.js, line 16872)
[Log] non touch event topClick time diff 366 (react-with-addons.js, line 16872)

---

[Log] touch event topTouchStart 1409061349552 (react-with-addons.js, line 16870)
[Log] touch event topTouchEnd 1409061349767 (react-with-addons.js, line 16870)
[Log] non touch event topMouseMove time diff 47 (react-with-addons.js, line 16872)
[Log] non touch event topMouseDown time diff 49 (react-with-addons.js, line 16872)
[Log] non touch event topMouseUp time diff 50 (react-with-addons.js, line 16872)
[Log] non touch event topClick time diff 51 (react-with-addons.js, line 16872)

---

Also, lowering the threshold doesn't really make sense, who's going to switch between a finger and a mouse in 750ms? Probably some nerdy developer who's trying to double click using a finger and mouse :)

[iamdustan]

I’m fairly certain that the “click” isn’t an emulated event, but the somewhat input device agnostic event (similar to “input” instead of key* events on form elements).

The 300ms delay was to allow for double-tap to zoom gestures (and potentially other accessibility features).

Is there any idea or testing how this would interact with other browser features that disable the 300ms delay such as:

// IE10+
-ms-touch-action: none;

// Chrome 32+ for Android
<meta name="viewport" content="width=device-width, initial-scale=1">
// or
<meta name="viewport" content="user-scalable=no">

[iamdustan]

@s0meone

Also, lowering the threshold doesn't really make sense, who's going to switch between a finger and a mouse in 750ms? Probably some nerdy developer who's trying to double click using a finger and mouse :)

You mean like this? http://smus.com/touch-laptop-experiments/

[syranide]

@s0meone Oh right, the click/tap event has "intentional" delays, but all other emulated mouse events I assume would be called immediately.

[s0meone]

@iamdustan

You mean like this? http://smus.com/touch-laptop-experiments/

That looks pretty awesome! Never seen it before. But I think when you're about to support this interaction you probably won't use a tap handler but handle all the events separately.

@syranide
I know about the 300ms click delay. So by "intentional" you mean by React or are you talking about that 300ms delay? Because I've also seen delays on mousedown and mouseup and didn't see any intentional delays in React's source.

[s0meone]

@iamdustan I've tested this patch in the Chrome device emulator, which only has a delay of a few milliseconds. Ignoring the events works perfect.

Log:

---

touch event topTouchStart 1409062331329 react-with-addons.js?body=1:16870
touch event topTouchEnd 1409062331531 react-with-addons.js?body=1:16870
non touch event topMouseOver time diff 13 react-with-addons.js?body=1:16872
non touch event topMouseMove time diff 17 react-with-addons.js?body=1:16872
non touch event topMouseDown time diff 18 react-with-addons.js?body=1:16872
non touch event topMouseUp time diff 18 react-with-addons.js?body=1:16872
non touch event topClick time diff 19 react-with-addons.js?body=1:16