See Issue 806338 for some extra details.

If I'm remembering right it's sent to cancel any active flings when you touch the pad.

(If there's a real issue please be specific. Sending fling cancels it not in itself a bug, as this is generated intentionally by the gestures library to stop flings).

That might be reasonable, but it's sent even when there's no ongoing fling. WDYT?

input code at this low level has no idea if there's an ongoing fling. All we can do it send a cancel. It is ignored if there's no fling.

This code itself sends the ET_SCROLL_FLING_START, it could theoretically track that none has been sent since the last cancel, but maybe that's insufficient (if flings are specific to event targets or occur simultaneously, etc). I'll concede that this may be working as intended.

In more detail: it is still the case (though this in the process of changing) that the fling is done by the renderer somewhere inside InputHandlerProxy et al. or inside blink proper. Knowledge of when the fling has stopped was not propagated to the browser. To make sure that users could touch-down and immediately start scrolling, the input code sent fling stops on a touch-down. 

It seems like the client could possibly cancel flings as needed on touch down, or the fling cancel could be sent when a new scroll gesture begins, rather than on touch-down.

It's odd that we cancel flings on *touchpad touch-down*, where single finger gestures generally translate to cursor movement; scrolling/flinging should work independent of cursor movement.

Perhaps scroll cancel should be sent for a single finger touch-down on a touchscreen, but only for a two-finger touch-down on a touchpad?

+adlr

I am not sure what the desired UX is but I assume that this was discussed in the past and led to the current implementation. Andrew owns the gestures implementation and should have more context about this.

If touchpad needs to be able to cancel flings initiated from a different device, then that justifies why it's sending them all the time. It can't know when a fling has been initiated from another devices.

Note there's no "touch down" event for touchpads, unless you count the "fling cancel" event.

Even if a fling was initiated on the touchscreen, it's not obvious that touching a single finger to the touchpad (or even dragging that finger to generate mouse/cursor movement) should cancel the touchscreen fling.

At this point, I'm kinda playing devil's advocate to ensure our behavior is correct; Issue 806338 is fixed.