Specify passive: false for all touch event handlers.

[rachel-fenichel]

https://www.chromestatus.com/features/5093566007214080

The chrome default is changing as of version 56, in a way that breaks our touch handling.

https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit
https://docs.google.com/document/d/1mlUcJZHLyz1fip7CNEiU0w7JgcxBZUilvOwg0i9ZvQc/edit#
WICG/interventions#18

[dtapuska]

You should probably be able to set touch-action: none CSS style on these elements. I looked at the places you are calling preventDefault. Do you have a common CSS rule for items? Using passive: false is discouraged.

[rachel-fenichel]

touch-action: none is insufficient--it isn't implemented on firefox, safari, mobile firefox, or IE 9.

I'm still working to understand whether passive: false is the solution that we need.

We may be fine with the new default, but we will not be able to remove preventDefault calls, since we support browsers other than chrome.

[dtapuska]

Firefox is supporting touch-action; see https://bugzilla.mozilla.org/show_bug.cgi?id=1101628 but it might not be working yet. I don't think they have shipped pointer events just yet.

The warning should go away in Chrome if you call preventDefault but do have a touch-action. This is definitely needed for interop with iOS as you indicated.

[dtapuska]

Adding @RByers. @rachel-fenichel let us know if we can be of any assistance. We really don't want people using passive: false and need to understand their issues if that is really the case that you need. I was trying to understand some of the blocky code and I wondered if you could set it on your draggable class style.

[rachel-fenichel]

Blockly is a library that does drag-and-drop code editing in SVG. We have a scrollable workspace inside a div. Scrolling the workspace should not scroll the page outside. From my understanding, if I leave passive: true then I cannot prevent a scroll on the main page. Is that correct?

If so, what I want is passive: false. And touch-action: none is, again, insufficient, because it isn't implemented on all browsers.

[RByers]

It sounds to me like you just want to add touch-action: none on the workspace and to keep your preventDefault calls as-is. As @dtapuska said, Chrome's warning about preventDefault being ignored should go away as soon as you set touch-action (since we know the calls to preventDefault are still needed for other browsers, and they're redundant with touch-action in Chrome so there's no longer any harm in them being ignored).

[rachel-fenichel]

I will take a look and see if that works. It sounds reasonable.

I don't think any of the public demos are fully functional in touch right now because #885 hasn't landed there yet.

How much can I assume that desktop chrome's responsive mode will give me the correct behaviour for touch/debugging this? That is, do I need to go find a touchscreen laptop for debugging?

[RByers]

How much can I assume that desktop chrome's responsive mode will give me the correct behaviour for touch/debugging this? That is, do I need to go find a touchscreen laptop for debugging?

It should behave the same as touchscreen desktop as well as Android AFAIK (it shares most of the same code).

[rachel-fenichel]

Closed by using touch-action: none in the last five years.