Closed lojjic closed 5 years ago
We can’t remove the filter; that was added in 34c2657e2c4ae2a75c3e16ce23a79e064b63602f to avoid a [Violation] warning in Chrome.
I considered switching to pointer events, but it still isn’t supported in Safari, so it doesn’t seem ready. (Plus, I imagine it’ll be a pain to rewrite in terms of pointer events, and an even bigger pain to try to support mouse and touch in addition to pointer events.)
I think using Never mind, that’s also not supported in Safari.navigator.maxTouchPoints > 0
as the default touchable implementation sounds good, though.
We could still use navigator.maxTouchPoints if not undefined, though.
As of Chrome 70, d3-zoom no longer works out of the box when using touch on desktop touchscreens. This is because Chrome has removed the
ontouch*
element properties on desktop OSes, and d3-zoom'sdefaultTouchable
implementation relies on the presence of theontouchstart
element property as its feature detection. It therefore thinks touch events are unsupported, even though they still are.See https://www.chromestatus.com/feature/4764225348042752 for their explanation.
We can work around this on a case-by-case basis by overriding the
touchable
config with our own implementation viazoom().touchable(...)
, but it would be nice to have a more reliable feature detection indefaultTouchable
. It sounds like checking for the presence ofwindow.TouchEvent
should work ok but it would need proper cross-browser testing.Alternative solutions might be: removing the filter altogether and just letting it attach unused touch event handlers in all cases, or adding a PointerEvents-based code path since that's apparently the recommended long-term approach.