Unable to preventDefault inside passive event listener due to target being treated as passive

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

I'm getting this error linked back to

react-swipeable-views/src/SwipeableViews.js

Line 406 in 55e9290

// We are swiping, let's prevent the scroll event.

And I'm not sure the fix or what the real problem is. It's not affecting usage, but that will pollute the log constantly in chrome.

As for the warning from Chrome: sorry for the trouble, this is a breaking change in Chrome 56 to improve scroll performance. There's probably a missing touch-action CSS rule, which is necessary to support touch on IE/Edge anyway.

@RByers Thanks for the link to the touch-action I'm adding it to #164.
Side note, we have an extra level of complexity as we dynamically prevent the scroll. We wait for a clear signal from the user that he wants to swipe and not to scroll. We will see if adding the class dynamically works.

Interesting. touch-action takes effect just before the touchstart listener is invoked. So you can change it dynamically between gestures, but not once a gesture has started (the whole point is that we don't want to wait for JavaScript to decide whether scroll can start). Is that good enough for your case, or do you want to make the decision based on something that has happened after the user's finger has contacted the screen? I.e. what's the distinguishing factor between a swipe and a scroll?

do you want to make the decision based on something that has happened after the user's finger has contacted the screen

We wait some touchmove events to deduce the user intention. The heuristic is implemented here.
Chrome has a similar logic internally, but our check is more restrictive to apply first.

Interesting. touch-action takes effect just before the touchstart listener is invoked.

Oh, that sounds like a dead end. Hopefully, blocking the scroll is a nice to have feature. We can live without.

@oliviertassinari - my testing of dynamically changing touch-action is that it's more complex and subtle than as described in @RByers' comment above. AFAICT, Chrome defers making a decision on whether a gesture should cause scrolling until the first touchmove event is dispatched. At that point, it looks at the direction of movement and compares it against the settings in the touch-action style as recorded prior to touchstart being dispatched. If the direction changes after this (e.g. the first movement is horizontal and is then followed by vertical movements) the style is checked again, and this check uses the current version.

Chrome defers making a decision on whether a gesture should cause scrolling until the first touchmove event is dispatched. At that point, it looks at the direction of movement and compares it against the settings in the touch-action style as recorded prior to touchstart being dispatched

This is all accurate.

If the direction changes after this (e.g. the first movement is horizontal and is then followed by vertical movements) the style is checked again, and this check uses the current version.

If this is true it's a bug (and probably not interoperable with Edge, or something that'll remain reliable in Chrome as we make more performance optimizations). Looking at the style is done only here in TouchEventManager::UpdateTouchAttributeMapsForPointerDown which is invoked only before dispatching touchstart. Can you provide a repro?

/cc @dtapuska @flackr