Added non-passive event listeners to scroll-blocking 'touchstart' and 'touchmove' events

[darcyparker]

In recent releases of Chrome, if you turn on 'verbose' logging for the console, you will see these violations: (Try this with http://dygraphs.com/ as an example)

[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952
[Violation] Added non-passive event listener to a scroll-blocking 'touchmove' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

I traced it this:

• this block in Dygraph.prototype.createDragInterface_ https://github.com/danvk/dygraphs/blob/ac422b3aa23612c220b14e938fbae79d01b40b86/src/dygraph.js#L1173-L1177
  • which calls Dygraph.prototype.addAndTrackEvent: https://github.com/danvk/dygraphs/blob/ac422b3aa23612c220b14e938fbae79d01b40b86/src/dygraph.js#L3402-L3405
  • which calls utils.addEvent: https://github.com/danvk/dygraphs/blob/c33b49f95618b6c5891dbef82ee76ea69ce3c783/src/dygraph-utils.js#L98-L100 (a wrapper for addEventListener)
• {eventName, handler} pairs from interactionModel are:
  • DygraphInteraction.startTouch https://github.com/danvk/dygraphs/blob/aa0b189f8cb22d64ce65cc9b205c90f6e4fd1257/src/dygraph-interaction-model.js#L411-L470
  • DygraphInteraction.moveTouch https://github.com/danvk/dygraphs/blob/aa0b189f8cb22d64ce65cc9b205c90f6e4fd1257/src/dygraph-interaction-model.js#L475-L563

It looks like moveTouch doesn't use preventDefault() (and I believe fns it calls don't call it either), so I think there is an opportunity to eliminate one of the violations for it by updating utils.addEvent with an optional argument something like fnDoesNotCallPreventDefault, and if true, call addEventListener with options: {capture: false, passive: false}. (See https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener). Then update downstream usage to use this fnDoesNotCallPreventDefault argument if we know the handler doesn't use preventDefault() inside it.

I don't understand the code sufficiently to say whether the startTouch handler can stop using preventDefault...

Side note: Could this issue be connected to https://github.com/danvk/dygraphs/issues/731 ? (The link mentioned in its description is broken... so I can't say)