Swiping on apple mac trackpad scrolls two slides and ignores FlickMaxPages setting

[go6media]

Checks

• Not a duplicate.
• Not a question, feature request, or anything other than a bug report directly related to Splide. Use Discussions for these topics: https://github.com/Splidejs/splide/discussions

Version

3.6.9

Description

When using TTB direction slider and WHEEL true and RELEASEWHEEL True , swiping past a slider on an apple track pad (not a physical mouse wheel) causes two slides to swipe instead of one at a time,

Settings are

var splide = new Splide( '#chapter_list', {
  direction: 'ttb',
height   : '70vh',
 wheel       : true,
 releaseWheel: true,
updateOnMove :true,
cloneStatus :false,
flickMaxPages :1,
waitForTransition :true,

} );

Reproduction Link

https://www.travelport.com/plus/simpler-travel-retailing

password = go6

Steps to Reproduce

1. Scroll down to the slider where it says LATEST RELEASE
2. swipe your trackpad naturally and you will see it swipe past two slides instead of one

Expected Behaviour

Only one slide should swipe at a time

[realjoshharrison]

I'm also experiencing this. It happens because the Apple trackpad and magic mouse emit wheel events for a while after the scroll gesture has been released. Here's a reduced test case: https://jsbin.com/saguqeqixu/edit?html,js,output

There's probably a better way to do this, but through trial and error in the past the only way I found to detect these "residual" wheel events was by debouncing the event with a timeout of 300ms before considering it to be a new gesture. This might give a good starting point for a solution? E.g. https://jsbin.com/newesorofo/1/edit?html,js,output (I've only included logic to advance the slide on wheel for this quick mockup)

[dolphin-wood]

My approach is to compare the difference of evt.deltaY between two wheel events, and scroll only if:

1. previous.deltaY * current.deltaY < 0, which means the scroll direction changed, or
2. abs(current.deltaY) > abs(previous.deltaY), which means the user was likely to start a new scroll, as the delta value should continue to descend in an ideal inertial scroll (e.g. 42 -> 24 -> 15 -> ... -> 0)

In practice, you may also need to set a threshold to reduce noise:

const threshold = 10;
let lastDeltaY = 0;
let isTrackpad = false;

el.addEventListener('wheel', (e) => {
  const { deltaY } = e;
  const diff = Math.abs(deltaY) - Math.abs(lastDeltaY);

  // additional check for trackpads
  if (!isTrackpad) {
    isTrackpad = diff !== 0;
  }

  const isNewScroll = isTrackpad ? diff > threshold : true;
  const isDifferentDirection = deltaY * lastDeltaY < 0;

  lastDeltaY = deltaY;

  if (
    splide.state.is(Splide.STATES.IDLE) &&
    (isDifferentDirection || isNewScroll)
  ) {
    splide.go(deltaY > 0 ? '>' : '<');

    // reset the flag in case that the user changes devices
    isTrackpad = false;
  }
});

Full-page demo: https://kgov1.csb.app
Sandbox: https://codesandbox.io/s/splide-wheel-kgov1

[go6media]

full-page demo: https://kgov1.csb.app/

Unfortunately, I am still able to scroll multiple slides at once on your demo using the mouse wheel.

demo https://www.loom.com/share/615934a846f64e7dbf186cad812c6db1

[dolphin-wood]

@waynep16 it's a by-design behavior if you continuously scroll the mouse wheel. Otherwise I think it's a bit weird to see the slider stuck at one scroll. 🤣

[ogelin]

@idiotWu I was also facing this issue and the above solution works great. Thanks.

[go6media]

el.addEventListener('wheel', (e) => {

I am getting el is not defined ReferencError here.

[BartekKonopka]

@waynep16 please, check this solution:

var splide = new Splide( '#chapter_list', {
    type: 'fade',
    wheel : false,
} );

splide.mount();

function handleWheel(e) {
    wDelta = e.wheelDelta < 0 ? 'down' : 'up';
    if( wDelta == 'down' ) {
        splide.go('>');
    } else {
        splide.go('<');
    }
    
    window.removeEventListener("wheel", handleWheel);

    setTimeout(()=>{
        window.addEventListener("wheel", handleWheel);
    }, 1000); 
}

window.addEventListener("wheel", handleWheel);

[go6media]

@waynep16 please, check this solution:

That is in place here https://www.travelport.com/plus/simpler-travel-retailing but still no joy :(

[dolphin-wood]

el.addEventListener('wheel', (e) => {

I am getting el is not defined ReferencError here.

@waynep16 el is the element you initialized splider to, for example:

const splider = new Splide('#container');

const el = document.querySelector('#container');

el.addEventListener(...);

[NaotoshiFujita]

The key of this issue is how to deal with the decrementing delta of the inertial scroll caused by trackpads and some trackballs. Currently, Splide treats any delta as a scroll and moves the slider because if there is a delta, it should consider that scroll is requested regardless of its amount. On the other hand, Splide quantizes scrolling as the slide transition, it can be inconsistent to treat that all deltas have same values (to move the slider).

Since there is no common solution for all use cases, I'm planning to add the configurable threshold for the delta. You can try the demo here (I stole Wu's demo):
https://codesandbox.io/s/wheel-threshold-g9snk

[realjoshharrison]

Thanks for taking a look @NaotoshiFujita!

It is a tricky issue. The configurable threshold works nicely to trigger just one slide change for a "strong" scroll on my macbook trackpad, but a gentle scroll now results in no slide change at all, unless the threshold is reduced to the point that the original issue occurs again on "strong" scrolls.

Building on the example, I've found what I hope is a good solution for all use cases... by comparing the current event delta with the previous event delta, we can detect an increase in momentum (ie a new scroll) and trigger a slide change accordingly regardless of the scroll strength and without needing to wait for a debounce timer to finish: https://jsbin.com/nejiyeqine/1/edit?js,output

I haven't tested this on a normal mouse wheel yet, only a trackpad. I will have a go tomorrow and report back.

[NaotoshiFujita]

I'm not aiming to limit the number of slides per "trackpad scroll" to 1. If the user makes a "strong" scroll, that means he/she wants to scroll a lot. Limiting the number to 1 often leads terrible UX. I understand the developer's intention to show slides one by one. It might be okay for the first visitor, but returning users may want to see the middle or the last slide. If there are 10 slides, the slider always forces users to swipe 10 times. Restricting the number kills the nice wheel advantage.

What I have to solve is that a "gentle scroll" unexpectedly skips a next slide, caused by the trackpad inertia. By the threshold above, developers can determine what is "gentle" and what is "strong" (they can also adjust the transition duration to wait the inertia somewhat).

Unfortunately, observing the delta change is untrustworthy. A mouse scroll sometimes gets stuck in your example. I think it's because my mouse emits different deltaY according to my scroll strength. Besides, surface/logicool trackpad emits both decrementing deltas and constant deltas. For example on the logicool (surface's is not like this):

300, 300, 300, 300, 300, 200, 200, 200, 200, 150, 150, ......

So, there is no way to detect trackpad-like devices just by observing the momentum.