Re: Send touchcancel when scrolling starts?

On Fri, Jun 21, 2013 at 2:23 AM, Wes Johnston <wjohnston@mozilla.com> wrote:

> > In contrast, Firefox, Chrome deskop, and mobile safari on divs with
> > -webkit-overflow-scrolling:auto all behave in the simpler but slower
> > fashion. Each scroll frame is blocked on the touchmove event, and
>
> > calling preventDefault on any touchMove can temporarily stop the
> > scroll. This is certainly best for compatibility and gives the site
> > the most control, but it's terrible for scrolling performance (which
>
> > we know is critical to engagement). Sites seem to often have
> > unnecessary touch handlers (eg. due to a desire to use event
> > delegation) and people don't realize how it contributes to scroll
> > jank.
>
> FWIW, this is NOT true of Firefox for Android or B2G (and shouldn't be for
> touch enabled Metro Firefox once they have OMTC turned on). i.e. We do NOT
> block scrolling while waiting for content to process EVERY touchmove event.
> We do block for a short time during the start of a scroll (200ms I think),
> or until we've heard back from content that preventDefault wasn't called on
> touchstart of the FIRST touchmove, whichever comes first. In fact, the spec
> is fairly specific about this: "If the preventDefault<https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#dfn-preventdefault>method is called on the FIRST
> touchmove<https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#dfn-touchmove>event of an active
> touch point<https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#dfn-active-touch-point>,
> it should prevent any default action caused by any touchmove<https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#dfn-touchmove>event associated with the same active
> touch point<https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#dfn-active-touch-point>,
> such as scrolling."
>

Ah, interesting - thank you!  I can see this behavior now in current
Firefox Android builds (eg. using this test page:
http://www.rbyers.net/janky-touch-scroll.html).  Sending all but the first
touchmove async and treating them as uncancellable is an interesting
alternative approach.  I've never interpreted that section of the spec to
mean we should do that - just that the first must be cancellable, but the
behavior on the others are implementation dependent (may or may not be able
to stop scrolling).

Your approach is also closer to the behavior of the Android stock browser.
 There it appears as if the touchmove events are sent async (scrolling is
not blocked on them), but cancelling them can still cause scrolling to
(eventually) stop.

As an aside, I dislike the 200ms timeout.  We've just added that to Chrome
Android as well, but I hope it's a temporary hack.  It means that
performance issues (perhaps not directly under the developers control) can
cause correctness problems, and is especially bad when the browser has some
overscroll action (like back/forward on ChromeOS).  I believe the right
long-term solution here is to require the developer to specify where
scrolling should be disabled declaratively in CSS, eg. with touch-action (
http://www.w3.org/TR/pointerevents/#the-touch-action-css-property)

We also do not (currently) on Firefox for Android send touchcancel when we
> start scrolling. In fact, we continue to send touchmove events. I have no
> idea if there's a strong usecase for allowing scrolling while still sending
> touch events. Perhaps on pages that want to do some sort of horizontal
> transform while also scrolling vertically? There isn't much jank associated
> with it because, as I mentioned, we have OMTC on all the platforms where we
> support touch. I don't have strong feelings about sending a touchcancel and
> killing all events after that if people want to though.
>

I think either of these approaches is workable.  Ideally I'd like to get
consensus on which is better and have both Chrome and Firefox follow the
same model if possible.

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?

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?

Thanks,
  Rick


>
>
> - Wes
>
>