Closed Bug 1605755 Opened 3 months ago Closed 3 months ago

[APZ] No scrolling acceleration available for touchpad input

Categories

(Core :: Panning and Zooming, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla74
Tracking Status
firefox74 --- fixed

People

(Reporter: sawyerbergeron, Assigned: sawyerbergeron)

Details

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

  1. Scroll quickly down on a page
  2. Perform an upward gesture for same distance, but slower velocity

Actual results:

Page arrives at same location as start

Expected results:

Page should be offset, biased toward the direction the faster gesture happened in

Applications where expected behavior present: Microsoft Edge, Safari, Cocoa native apps (OSX)

Scroll acceleration in practice tends to make scrolling feel subjectively "snappier", more responsive, more "natural"

A user configurable amount of touchpad scrolling acceleration should be added, with curve/function to TBD. Some platforms provide this natively in touch drivers (some windows touchpad drivers) and others rarely provide it natively (wayland on linux/evdev/libinput)

The curve should ideally allow negative acceleration as well, for individuals who wish to counteract platform provided acceleration for accessibility related reasons

Filed as continuation of discussion from https://bugzilla.mozilla.org/show_bug.cgi?id=1604330

Related functionality appears to have been implemented in the past (potentially), but recent digging only turns up acceleration for actual mouse wheels (https://bugzilla.mozilla.org/show_bug.cgi?id=1401844)

If someone on OSX could confirm the platform native behavior that would be super helpful here (both in first party applications and in firefox)

Current proof of concept that subjectively feels "natural" is attached, any final implementation should abstract out any constants into StaticPrefs

Potential enhancement for user familiarity would be to add a threshhold below which scrolling acceleration is linear/not applied (more predictable for precise movements) as visually reflected in https://pavelfatin.com/scrolling-with-pleasure/#scrolling-acceleration

Attached patch ff_poc1.diff (obsolete) — Splinter Review
Attached patch ff_poc3.diffSplinter Review

This change adds configuration options in static prefs to change the acceleration profile.

Subjectively a number in the range 1.33-1.37 feels most natural, but default is 1 to avoid disrupting what people may be used to.

It may make sense to have different behavior between platforms for the default as well.

From testing on microsoft edge and google chrome on windows, it appears there is no linear segment at slow speeds (acceleration is always exponential) so a simple exponential profile here may make the most sense to preserve consistency.

Attachment #9117570 - Attachment is obsolete: true

Thanks for the patch, Sawyer! Could I ask you to submit it to our Phabricator code review system please?

Assignee: nobody → sawyerbergeron
Priority: -- → P3

(In reply to Botond Ballo [:botond] from comment #6)

Thanks for the patch, Sawyer! Could I ask you to submit it to our Phabricator code review system please?

Happily.

I seem to be having trouble adding you as a reviewer, r=botand is rejected by moz-phab for me, is just adding that on the end of the commit title not correct?

(In reply to Sawyer Bergeron from comment #7)

I seem to be having trouble adding you as a reviewer, r=botand is rejected by moz-phab for me, is just adding that on the end of the commit title not correct?

It should work with the typo fixed (r=botond) :)

Whoops, fixed/submitted. Thanks for catching that :)

Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74

Is this something we should add some non-1 factor to by default? Not sure if default should be accelerated scrolling or not.

Flags: needinfo?(botond)

We can try to make it accelerated by default.

I would suggest we proceed cautiously: first change it on the nightly channel only, and wait a while to see if we receive any user feedback.

Would you be able to try some other Linux browsers (e.g. Chrome Linux, Epiphany) and compare the behaviour? If the change brings us closer to other Linux browsers' behaviour, that's an encouraging sign.

Flags: needinfo?(botond)

I think I see very slight acceleration in Chromium-Ozone on wayland, and GTK states that they have scrolling acceleration from what I can find (https://gitlab.gnome.org/GNOME/gtk/issues/695) but Epiphany doesn't seem to have any noticeable acceleration and other native GTK apps for me on X don't display any noticeable acceleration.

Adding acceleration would probably move us out of alignment with general platform behavior, though it seems intent for the platform is for there to be acceleration for touchpads (responsibility tends to bounce around for where it should be implemented, primary discussion in https://gitlab.freedesktop.org/libinput/libinput/issues/252 which references GTK bug https://gitlab.gnome.org/GNOME/gtk/issues/1308. Older discussion about this for scroll wheels is at https://gitlab.freedesktop.org/libinput/libinput/issues/7.

Recent opinion from Peter Hutterer (libinput maintainer) in https://gitlab.freedesktop.org/libinput/libinput/issues/105 is "yes, add scroll acceleration. But add it in GTK/Qt, not in libinput. 5 years down the track you'll have less grey hair and regrets because of it." so I'm not sure how to pull all of that into a single opinion on whether the default for this should be set in Firefox, it gets complicated fairly quickly. I might open a bug report for GTK about what the status of scrolling acceleration is and what current plans are for it. Qt may follow but they have issues with smooth scrolling in general (doesn't work on Wayland currently, spotty on X.)

QA Whiteboard: [qa-74b-p2]
You need to log in before you can comment on or make changes to this bug.