Incompatible with passive event listeners

[rjgotten]

When used with recent Chrome builds that support passive event listeners, touch interaction leads to a massive spew of errors:

Unable to preventDefault inside passive event listener due to target being treated as passive. See https://www.chromestatus.com/features/5093566007214080

PhotoSwipe needs to detect passive event listener support and explicitly register its document level touch handlers with a passive: false option.

[dimsemenov]

I've heard that Blink is planning to make {passive:true} by default, WICG/interventions#18

What's the lightest way to detect passive events? Anything more compact than:

var supportsPassive = false;
if(Object.defineProperty) {
    var opts = Object.defineProperty({}, 'passive', {
        get: function() {
            supportsPassive = true;
        }
    });
    window.addEventListener('test', null, opts);
}

?

[rjgotten]

That's the lightest way to do it, as far as I'm aware.

[dtapuska]

It looks like you use pointer events why aren't you checking window.PointerEvent and using the MS specific value instead (navigator.pointerEnabled).

That would likely mitigate it because pointer events is going out before the passive event listener intervention.

[dimsemenov]

@dtapuska, it's a good point, I plan to drop msPointerEnabled and check for just window.PointerEvent in the next major release, usage of IE10 is very low and it can always fall back to mouse events.

[dtapuska]

FYI... Chrome pointer events are enabled in beta, dev and canary. The intervention is only enabled in canary and dev.

[RByers]

Sorry for the trouble, this is now a breaking change in Chrome 56 to improve scroll performance. You can probably fix this by adding an appropriate touch-action CSS rule.

[capuski]

I'm still having problems with this issue. Because of this, when you use photoswipe on mobile devices, when you swipe to close a image, the page jumps to the top, really bad =/

[rjgotten]

@RByers
Photoswipe already adds a touch-action:none to its top element that contains the component's entire UI.
It is not a magical cure-all for all issues related to Chrome's misguided scroll-performance intervention.

You cannot get rid of the event.preventDefault() calls here. Because for browsers that don't support touch-action in conjunction with touch events, you must use event.preventDefault() to cut out native touch behavior. That includes Firefox 51 and lower, because touch-action only became enabled by default from version 52 onwards, and all current and old versions of Safari, which support only the auto and manipulation values at best, which falls short of supporting all possible UI interaction patterns.

Even if touch-action can be used to remove the functional issue of native touch behavior continuing to run in Chrome, that will still continue to generate massive amounts of console warning spam:

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

The only proper way to fix this cross-browser, including getting Chrome to shut its trap, is to employ a bit of intermediary code around libraries' addEventListener calls which detects passive event handler support and sends an explicit passive:false for those browsers that support it.

[RByers]

Adding touch-action: none without changing any of the existing code that calls preventDefault should absolutely be a "magical cure-all". Chrome's console warning is disabled as soon as we detect touch-action is used at all (i.e. it errs on the side of under-warning, not over-warning). If you can provide a repro case that doesn't match what I've described here, we'd treat it as a high priority bug and investigate / fix ASAP.

[rjgotten]

Adding touch-action: none without changing any of the existing code that calls preventDefault should absolutely be a "magical cure-all". Chrome's console warning is disabled as soon as we detect touch-action is used at all

That makes it a magical cure-all only for Chrome, and that's only in the best case scenario.

It's wholy possible and often very desirable to cancel only part of the native behavior and thus the touch-action value continues to need tweaking and case-by-case solving. Just dumping in a touch-action:none and calling it a day does not suffice.

You've also done nothing to address the problems with iOS Safari which supports only a limited subset of touch-action values and which would all but require the infusion of some form of unholy marriage of touch-action and event.preventDefault() to keep everything working.

[basakil]

Added (& tried many combinations of) 'touch-action: none;' everywhere from html to holder div, but error deluge did not cease in any case. Sometimes the list does not respond to dragging, but most of the time works fine even if it does is slower. Error Lines are 612 & 1501 consecutively. Any hope for a fix or recommendation of another cure?

[dimsemenov]

Sometimes the list does not respond to dragging

@basakil, which list? This is PhotoSwipe repo, and it already has touch-action:none on its root element, so preventDefault won't make any difference in browsers that support touch-action.

[basakil]

Oh maan! I thought this was the Sortable group... Sorry.

[dimsemenov]

fixed by v5.0