Fix scroll to seek/change volume/playback rate changing too fast with touchpad

[PikachuEXE]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

Closes #6539

Description

wheel triggered N times more than mouse wheel with smaller delta values to have smooth scrolling
This PR throttles event handler on value change side only (prevent default/stop propagation still called all the time

Screenshots

With 100ms wait time, trackpad

Screen.Recording.2025-01-29.at.10.21.52.mp4

Testing

A) Those without trackpad
See #6539, test with mouse wheel ensure it works similar to/same as before

B) Those with trackpad
#6539

Desktop

• OS:
• OS Version:
• FreeTube version:

Additional context

I tested 50ms wait and it seems too fast
(Too lazy to record that too

[PikachuEXE]

Custom build: https://github.com/PikachuEXE/FreeTube/actions/runs/13023462048

[efb4f5ff-1298-471a-8973-3d47447115dc]

it seems slow but that could be because im testing on a trackpad

[PikachuEXE]

Feel free to change the 100ms values to something else to see how it feels
To me 50ms seems too fast (on macOS trackpad
No idea how other OSes handle trackpad scrolling

[efb4f5ff-1298-471a-8973-3d47447115dc]

I let the others chime into this one as i find it difficult to evaluate what a good speed for this is

[PikachuEXE]

I rarely use trackpad not to mention scrolling
So same as you

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[efb4f5ff-1298-471a-8973-3d47447115dc]

@absidue @ChunkyProgrammer @kommunarr your input is needed

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[ChunkyProgrammer]

@absidue @ChunkyProgrammer @kommunarr your input is needed

I don't have a laptop so I can't really test this/suggest a good speed

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[checktext00]

scrolling rate/speed is perfect with the new build,

but, there is a a bit of rubber-banding feeling with the scrolling (like I could scroll the volume from 50% to 100%, but it will settle on 95%), and also it doesn't always scroll smoothly, but that's not a major issue.

also there is still the lack of ability to reverse the scrolling direction for the following 3 settings in the FreeTube app settings > Player section:

• Scroll Volume Over Video Player
• Scroll Playback Rate Over Video Player
• Skip by Scrolling Over Video Player

[efb4f5ff-1298-471a-8973-3d47447115dc]

@PikachuEXE can you rebase into dev. Im having playback issues

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[PikachuEXE]

New custom build: https://github.com/PikachuEXE/FreeTube/actions/runs/14505024327

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[efb4f5ff-1298-471a-8973-3d47447115dc]

@PikachuEXE can you rebase into dev. Im having playback issues

Probably best to rebase again and provide a new build

[PikachuEXE]

Rebased and build started: https://github.com/PikachuEXE/FreeTube/actions/runs/14853765114

[efb4f5ff-1298-471a-8973-3d47447115dc]

I do have mixed feelings about this PR. It makes the UX with a scroll wheel objectively worse but makes trackpad more manageable.

I've tested this with trackpad again on nightly and with this change. The before doesnt seem that bad. It requires some getting used to because the swiping gestures have to be made slower in order to decrease/increase the volume by a bit.

I think i would choose having a bad trackpad over a bad scrollwheel + the fact that only one user reported this makes me think that this isnt that big of a deal

Not blaming the implementation here but this seems to be a case of pick the lesser evil one. if no acceptable middle ground can be found then we should close this

[absidue]

The way our mouse volume/skip scrolling currently works is by using hardcoded jumps for each event, so one event equals:

• 5% volume
• default skip interval * playback rate
• 0.05x playback rate

On trackpads scrolling on a page is generally smoother whereas with a mouse it tends to jump a bit. Unconfirmed theory: Trackpads send events more frequently but each event is for a smaller "scroll distance", mice send less frequently but each event has a larger "scroll distance".

This pull request currently addresses the too large jumps on touch pads by ignoring various events. If my theory above is correct we may instead be able to base the increases/decreases on the distance that was scrolled (deltaX, deltaY and deltaMode) instead of hardcoded values (we would likely have to normalise the values a bit instead of using the raw "scroll distance"), that way it would hopefully even out/make it more similar for mice and trackpads.

[PikachuEXE]

The values in event.deltaY are +/-120 via wheels and +/-1 in trackpad
Problem is that the no. of events is too big to normalize the value changed (e.g. can't change volume by 0.1%... 1% per event = still too fast

Let me see if I can make it only use throttle when delta is small enough (and verify if what I mentioned above is correct, forgot

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days.