Dragging in mobile is buggy - scrolls page and triggers error

[itaibh]

When I switch to mobile mode in Chrome 55 and I try to drag some sortable element, I get this error on every "finger" move:

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

In addition, if the page has where to scroll, it scrolls.

If you want to see for yourself you can go to the official Sortable.js demo (http://rubaxa.github.io/Sortable/), open up dev tools, enable device emulation mode and start moving elements around.

[itaibh]

The easy fix (not sure if correct fix, though) is to update the implementation of the function _on in line 1017 (at least in my version) to:

    function _on(el, event, fn) {
        el.addEventListener(event, fn, {capture: false, passive: false});
    }

meaning - to change the last parameter from false to {capture:false, passive: false}, since since chromium version 54 the default for passive mode in mobile devices changed to true.

[jeffreznik]

Can this please be fixed? The latest Chrome update broke Sortable.js on mobile.

[mackerson]

+1, working on Chrome 55 on android 7.1.1, broken on Chrome 56 on android 6.0.1. Also seeing this issue in mobile Safari. Reproducible on desktop Chrome 56 with device emulation enabled.

[mumblyOMOD]

+1

[RubaXa]

Fixed: 42f57f1

[mackerson]

Confirmed working on latest in chrome 56! Thank you! I just tossed some cash into the donation link on the site. I'm still seeing the behavior on mobile Safari, although the behavior is consistent with the way it was behaving on chrome - is it possible that Safari is also ignoring the preventDefault?

[RubaXa]

Quite possible.

[RByers]

Sorry for the trouble, this is a breaking change in Chrome 56 to improve scroll performance. Note that your fix isn't compatible with browsers that don't support EventListenerOptions - you may want to use feature detection.

However, it looks like your code also supports pointer events - which don't disable scrolling via preventDefault either (regardless of the passive setting). I checked in Microsoft Edge with a touchscreen and it's indeed broken there as well. I believe the right fix (for both pointer events and Chrome 56+ touch events) is to add a touch-action:none CSS rule to explicitly disable touch scrolling over any draggable item. I verified such a change fixes the demo so that it works properly on Edge.

[RubaXa]

@RByers try touch-action-branch (314db5e)

[SaeedPrez]

Thanks @RubaXa, the touch-action:none seems to have temporarily fixed the issue until you release next version.

[RubaXa]

So? Add or not it is in the master?

[elonmallin]

Hi, I think the way to fix it must be with feature detection as @RByers mentioned.
touch-action:none might solve it for some cases but what if you have a sortable list that takes up the whole screen? Then you can't scroll. The delay property is supposed to solve this I guess so that you can both scroll when touch dragging over your sortable list and start a drag if you press and hold for the delay.

So I guess something like the below?

var supportsPassive = false;
try {
  var opts = Object.defineProperty({}, 'passive', {
    get: function() {
      supportsPassive = true;
    }
  });
  window.addEventListener("test", null, opts);
} catch (e) {}
captureMode = supportsPassive ? {capture: false, passive: false} : false,

// remove this:
// el.style['touch-action'] = 'none'; // #1022

[RByers]

If you really want to support both touch scrolling and dragging based on how long the user holds their finger down after touchstart, then yeah using passive:false (and having potentially janky scrolling as a result) is unfortunately the only option today.

Can someone point to a demo where that works? I'm curious to see what the UX feels like - it sounds pretty strange to support both interactions with roughly the same gesture. Is this is a "long press to pick up and then drag" sort of UX?

[elonmallin]

Don't think there is a demo for this. But delay is something you set in the options object when you create your sortable. So you decide the milliseconds you want. It is not a totally uncommon use-case I guess. Every phone has their apps on the home screens, you can reorder if you first do a long press but also swipe left and right to get to another screen.

[RByers]

Thanks, yes I agree that with the right affordances that's a reasonable UX. Spec issue filed, thanks!

[RubaXa]

@elonmallin PR?

[elonmallin]

@RubaXa Sure, see if this works #1042

[RubaXa]

I specifically left the possibility: https://github.com/RubaXa/Sortable/blob/touch-action/Sortable.js#L70

[elonmallin]

#1043 Guess you meant that the PR should be in the touch-action branch? Also removed the touch-action:none.

[RubaXa]

Done.

[SaeedPrez]

@RubaXa when are you planning to tag a new release so we can update via NPM? Or is it possible to update without you first tagging?

[RubaXa]

Tomorrow.

[RubaXa]

sortablejs@1.5.0

[ohute-couture]

I installed sortablejs@1.5.1 and this bug was not resolved
(http://rubaxa.github.io/Sortable/)

1d1e781
The calling sequence seems to be a problem.
I ask for confirmation.

[nomanr]

1.5.1 not working on chrome for mobile or WebView chrome client. Any update on this issue? Thanks

[davidcp90]

1.6.0 is throwing the same error. Any ideas on how to fix it?

[yu1222]

Any update?

[wattrobert]

Just checking if this is still on the table for being fixed?

[owen-m1]

@wattrobert This error will not exist in the next version

[owen-m1]

In 1.8.1 it should now work