Touch events in Chrome Android
Today I came across some odd behaviour in Chrome Android. In our app we have a module that is responsible for listening for user touch events and responding by panning or swiping to the next page.
In Chrome Android our ‘touchmove’ event callback seemed not to be firing at all, and as a result the panning and swiping feature of our app was broken. After doing a quick timeline in Chrome Dev Tools I could see three events firing: ‘touchstart’, ‘touchmove’ and ‘touchcancel’. Wait … ‘touchcancel’ wat?!
I sent out a plea for help on Twitter, thankfully https://twitter.com/gauntface (Google Chrome) sent me this advice:
@wilsonpage There is a 200ms delay that you need to call e.preventDefault() in. However, the 200ms delay is dependant the time the system ..— Matt Gaunt (@gauntface)
Why was Chrome cancelling my touch events?
From https://code.google.com/p/chromium/issues/detail?id=260732, it seems as though it’s for performance reasons. Chrome probably wants to handle the touches for browser default events such as scrolling without the complication of handling any custom logic.
What’s the problem?
In order to listen to the touch events in Chrome Android I have to call
event.preventDefault();. If I ‘prevent default’ I am effectively say to the browser “leave this event alone, I’m handling it”.
This is fine, except we now lose the option of native
overflow: scroll; within any element that may reside within the element I’m listening for touches on. Preventing default on a ‘touchstart’ or ‘touchmove’ event will prevent any scrolling that would have been handled by the browser from occurring.
overflow: scroll; or
-webkit-overflow-scrolling: touch. In Chrome Android (unlike other browsers) this is appears not to be possible.
A work around
I understand handling custom and default responses to touch event must be a tricky one to manage for browsers. I’m just writing this up to highlight a use case that requires both responses. Microsoft’s
[http://msdn.microsoft.com/en-us/library/windows/apps/hh767313.aspx](-ms-touch-action) property from the http://www.w3.org/Submission/pointer-events/ does a good job giving developers control over how touches are handled by the browser, and could end up working its way into the other major browsers.