RE: Send touchcancel when scrolling starts?

> 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 method is called on the FIRST
          touchmove event of an active touch point, it should
          prevent any default action caused by any touchmove event
          associated with the same active touch point, such as scrolling." 

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.

- Wes