Re: Send touchcancel when scrolling starts?

Just a quick update: we're now thinking that the mobile Safari model (used
when scrolling the document - details below) is actually the better option
of the three, so we're going to give that a try first and see how it works
out in practice.  I'll follow-up again when we have some more concrete data
- hopefully we can still eventually all agree on the best model and ideally
have the WG add a note to the spec or something.

Details:
The reason Chrome Android originally chose the 'touchcancel on scroll'
model was that they found issues with some websites double-processing
touchmove events where a move would both scroll the page AND be handled by
JavaScript to change something in the application.  This is confusing from
a user perspective and can cause it's own scroll performance problems (due
to changing DOM while scrolling, etc.).  Have you guys seen any issues with
this in Firefox?

Mobile safari, on the other hand, just stops sending touchmove events
entirely when the document is being scrolled so double handling is
impossible, but you still get a touchend when the finger lifts (reducing
the problem of sites forgetting to add touchcancel handlers).  I don't know
why mobile Safari has made a different choice for scrolling divs (where you
always get touchmove events that block scrolling), but I suspect it's an
implementation detail (document scrolling is handled by the OS, where div
scrolling involves WebKit).  So we're going to try applying this model in
all scenarios (first behind a flag - http://crbug.com/240735).

If there are legitimate scenarios where an app WANTS to get async
notifications that scrolling is happening (and by how much, etc.), then
this is exactly what the 'scroll' event is for.  So suppressing the
touchmove events during scroll doesn't appear to significantly decrease the
capability of the app.

Thanks,
  Rick


On Wed, Jun 26, 2013 at 8:41 PM, Rick Byers <rbyers@google.com> wrote:

> On Wed, Jun 26, 2013 at 8:28 PM, Alexandre Elias <aelias@chromium.org>wrote:
>
>> On Fri, Jun 21, 2013 at 6:53 AM, Rick Byers <rbyers@google.com> wrote:
>>
>>>
>>> I haven't yet been able to find a real-world example of a site
>>> legitimately handling touch events while scrolling.  Your side-swipe
>>> example seems the most likely, but it'll be broken when zoomed or when
>>> horizontal panning is otherwise permitted (I think touch-action: pan-y is a
>>> better solution for this).  *Alexandre / Paul*, have you guys come
>>> across any sites that actually want this functionality from Android browser
>>> / Firefox / iOS?
>>>
>>
>> I haven't come across a compelling real-life example, no.  Certainly
>> there are use cases such as horizontal carousels on a vertically scrolling
>> page, but in that case it's not clear that allowing both movements at once
>> is better than locking to one axis (in my opinion locking is somewhat
>> preferable and matches the typical behavior of native touch apps).
>>
>>
>>>
>>> So perhaps the main disadvantage of sending the touchcancel is the
>>> compatibility implications.  Some developers don't realize they need to
>>> listen for it (although this can cause bugs elsewhere too), or that they
>>> need to cancel touchmove events they've handled.
>>>
>>> The main advantage of sending touchcancel is probably that it makes this
>>> choice explicit and lowers the risk that touchmove handlers will be
>>> accidentally causing reflow or other changes while scrolling.  Also being
>>> consistent with the pointer-events model is a benefit, but I think we could
>>> still implement touch-action for touch events without this property.  *Alexandre,
>>> *any other reason you guys prefer touchcancel to what Firefox is doing?
>>>
>>
>> No, the only benefit I'm aware of is the explicit nature of the
>> notification (which in principle may be useful, but in practice I'd be
>> surprised if any sites are doing anything with it today).
>>
>
> Thanks.  Given that our DevRel team has seen Chrome-Android-specific bugs
> in websites as a result of this (and the TouchEvents spec more closely
> matches what FF doing), perhaps we should give switching to the FF model a
> shot?  We'll take this off list and report back.
>
>
>>
>>
>>>
>>> Thanks,
>>>   Rick
>>>
>>>
>>>>
>>>>
>>>> - Wes
>>>>
>>>>
>>>
>>
>