Note that when the "touch" runtime enabled feature is disabled, we disable all the CC touch hit testing machinery.  So turning this off means we get touch events but probably either always fast touch scrolling, or broken touch events (as if all listeners were passive?).  Didn't check which.

The code is probably in this weird state because the --touch-events command line flag used to control touch support up at the top of chromium (so when it was off, blink would never even get any touch events).  sadrul@ changed that at one point as part of a cleanup.  We should probably rename / clarify the RuntimeEnabledFeature to make it clear that it controls the touch event API exposure (although disabling it doesn't hide it completely - we still want devtools touch emulation to mostly work when it's disabled).

Just preventing TE dispatch should be enough but need to consider possible side-effects of "disabled cc touch hit testing machinery". Trying to figure out, any comments?

Looks like touch-action could be affected.

Yeah we want the 'Touch' RuntimeEnabledFeature disabled so that touch event feature detection (like "ontouchstart" in window) doesn't pass.

But we need to make sure that CC touch hit-testing is still functioning for the sake of touch-action.  Perhaps CC touch hit testing should just always be active now - you never know when a touch screen could be plugged in via USB and we probably should handle that case for pointer events (which don't have the same constraints the TouchEvent API does).

dtapuska@ any thoughts?

If you can't construct a TouchEvent in JS; we shouldn't dispatch the events. And I do think we should always update the touch rects. Since this code would typically run on mobile which is lower powered there should technically be no reason not to enable it always on desktop.

 Issue 645121  has been merged into this issue.

@rbyers: With chrome://flags/#touch-events controlling only TouchEvent-feature-detection from M57, I think we are done here. In other words, we don't need a separate flag to suppress firing TouchEvent altogether, right?