|Web facing change PSA: touch scrolling will no longer send touchcancel in Chrome 36||Rick||5/5/14 1:26 PM|
tl;dr: We're trying again to tweak the behavior of touch events during scrolling to improve compatibility with other browsers, reduce developer confusion and give developers additional control while continuing to minimize the impact on scrolling performance.
Motivation / background
See the original motivation, background and risks from my original PSA below. Since then we've tweaked our approach to address the web compat impact we found.
New change details
The idea is that active scrolling (where the page or a div is tracking the finger) should cause touchmove events to be sent asynchronously as uncancelable events. These events will be explicitly marked with the Event.cancelable property set to false and will be throttled (eg. initially to at most one every 200ms) to limit any potential performance impact. When active scrolling terminates (eg. due to hitting the scroll limit) then future touchmoves should again be sent synchronously unthrottled and allowed to pause scrolling (if preventDefault is called on them). Applications can now rely on seeing a 'touchend' event when the user lifts their finger (regardless of whether scrolling occurred). See The throttled async touchmove model for details on the behavior.
As of r266585 we've switched the default --touch-scrolling-mode from our current 'touchcancel' to our new 'async-touchmove'. The flag is exposed at chrome://flags/#touch-scrolling-mode (for two milestones at most) so people can switch back to test the differences. See bug 346693 for more details.
On Thu, Apr 17, 2014 at 12:04 PM, Rick Byers <rby...@chromium.org> wrote: