Web facing change PSA: touch scrolling will no longer send touchcancel in Chrome 36

Showing 1-1 of 1 messages
Web facing change PSA: touch scrolling will no longer send touchcancel in Chrome 36 Rick Byers 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.

Rick

On Thu, Apr 17, 2014 at 12:04 PM, Rick Byers <rby...@chromium.org> wrote:
FYI, We're pushing this feature back a release while we address a compatibility issue with it.  The default touch scrolling mode has returned to 'touchcancel' in Chrome 35 but we hope to switch back to a new version of 'touchmove-absorb' in the next couple weeks (in time for Chrome 36).

Rick


On Fri, Mar 7, 2014 at 4:09 PM, Rick Byers <rby...@chromium.org> wrote:
tl;dr: We're tweaking 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.

Background and motivation
Browsers differ markedly in how touch events are handled during a scroll, which is left as an implementation detail in the TouchEvent specification (the specification's goal was to retroactively capture the behavior common between the major browsers).  There's a fundamental tension between scroll smoothness and developer control.  Chrome on Android has always had a unique approach of sending a 'touchcancel' event as soon as scrolling starts and then suppressing all further touch events for the duration of the scroll (in effect favoring scroll smoothness above all else).  This breaks some websites and has been responsible for a lot of confusion for developers who aren't even aware of the touchcancel event (which is otherwise only fired in rare situations).  It also makes certain UI effects (like pull to refresh) impossible to implement without also re-implementing scrolling and fling physics in JavaScript (which breaks consistency with the platform).

Change details
The idea is that active scrolling (where the page or a div is tracking the finger) should 'absorb' the touchmove events causing it, but when active scrolling terminates (eg. due to hitting the scroll limit) then future touchmoves should again be sent synchronously and allowed to pause scrolling.  Roughly this means that the page will see either a 'touchmove' or 'scroll' event for any finger movement.  Applications can now expect to see a 'touchend' event when the user lifts their finger (regardless of whether scrolling occurred).  See touchmove absorption for details on the behavior.

In bug 346693 I'm switching the default --touch-scrolling-mode from our current 'touchcancel' to our new 'absorb-touchmove'.  I'll expose the flag at chrome://flags/#touch-scrolling-mode (for two milestones at most) so people can switch back to test the differences.

Risks
My main concern is avoiding any impact on scrolling performance in common scenarios.  There are some scenarios where we know performance will be affected, but we think they should be rare.  See the design doc for details.

It's also possible (but seems unlikely) that some websites explicitly designed for Chrome's touchcancel behavior could be broken by this change.  Such sites would need to update to support 'scroll' events as a signal of the start of scrolling (which they'd probably want for other browsers anyway).  We believe however that there are still many more websites that will be fixed by this change (eg. because they forgot to listen for touchcancel at all) than will be broken by it.

If you see a page/scenario that behaves worse while touch-scrolling (or for that matter better) in M35 than it did in M34 (or with --touch-scrolling-mode=touchcancel) please let me know.  We expect we may need to iterate on the details over the next couple milestones, and worst case we can revert to touchcancel mode.

Thanks,
   Rick