Four different models of touch event processing?The behavior differences between the browsers break down into four models.
- Normal synchronous event processing
Touchmove events are sent during scrolling and each scroll update blocks until touchmove handling has completed. This is good as the simplest to understand and the most powerful but bad for scroll performance because it means that each frame during the scroll must block on the main thread.
Browsers: Android Browser (Android 4.0.4, 4.3), Mobile Safari (when scrolling div)
- Asynchronous touchmove processing
Touchmove events are sent during scrolling, but scrolling can proceed asynchronously (the touchmove event is ignored after scrolling has begun). This can result in "double handling" of events, for example, continuing to scroll after the web site does something with the touchmove and calls preventDefault on the event, telling the browser not to handle it.
Browsers: Mobile Safari (when scrolling Document), Firefox
- Touchmove suppressed while scrolling
Touchmove events are not sent after scrolling starts and do not resume until after the touchend event. In this model, it's hard to tell the difference between a stationary touch and a scroll.
Browsers: Samsung Browser (mousemove events sent)
- Touchcancel on scroll start
You can't have it both ways -- scroll smoothness and developer control -- and this model makes clear the trade-off between smooth scrolling and event handling, similar to the semantics of the Pointer Events specification. Some experiences that may need to track the finger, like pull-to-refresh, are not possible.
Browsers: Chrome Desktop M32+, Chrome Android