Touch scrolling will no longer send touchcancel in Chrome 35

We're making a pretty major change to how we handle touch events while
scrolling in chromium.  I'm optimistic that this will be better for
compatibility and developer control without sacrificing performance, but
it's still somewhat experimental.  It'll be a couple months before we know
for sure that we'll be shipping this way in Chrome stable.

I'm happy to hear any feedback or questions you have (on this thread, or as
comments in the design doc below).

Thanks!
   Rick

Text links to they key resources below (for the list archive which doesn't
include HTML):

Touch move absorption design doc:
https://docs.google.com/a/chromium.org/document/d/1MGuCb0Lb7UfaDmH44bp9YKVG-CVfH6WtKTZl93BXwQw/edit#

Notes on how different browsers behave here:
https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7

Notes on pull-to-refresh experiments for the web:
https://docs.google.com/a/chromium.org/document/d/1cBYKZMCeeaT6pN3VYu9uox8AXbJKmOaEmpL4BTg5lT4/edit#heading=h.n1849rs1xni3


---------- Forwarded message ----------
From: Rick Byers <rbyers@chromium.org>
Date: Fri, Mar 7, 2014 at 4:09 PM
Subject: Web facing change PSA: touch scrolling will no longer send
touchcancel in Chrome 35
To: Chromium-dev <chromium-dev@chromium.org>
Cc: blink-dev <blink-dev@chromium.org>, input-dev <input-dev@chromium.org>


*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<https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7>,
which is left as an implementation detail in the TouchEvent
specification<http://www.w3.org/TR/touch-events/>(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 <http://crbug.com/293467> 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<https://docs.google.com/a/chromium.org/document/d/1cBYKZMCeeaT6pN3VYu9uox8AXbJKmOaEmpL4BTg5lT4/edit#>)
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<https://docs.google.com/a/chromium.org/document/d/1MGuCb0Lb7UfaDmH44bp9YKVG-CVfH6WtKTZl93BXwQw/edit#>
for
details on the behavior.

In bug 346693 <http://crbug.com/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<https://docs.google.com/a/chromium.org/document/d/1MGuCb0Lb7UfaDmH44bp9YKVG-CVfH6WtKTZl93BXwQw/edit#>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