Closed Bug 1678771 Opened 4 years ago Closed 3 years ago

scrolling via touchpad in Library window is insanely over sensitive

Categories

(Core :: Layout: Scrolling and Overflow, defect)

Firefox 84
Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox92 --- fixed

People

(Reporter: billdillensrevenge, Assigned: tnikkel)

References

Details

Attachments

(4 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Open Library window and go to History or Bookmarks (only if you have a lot of bookmarks though). Scroll via touchpad. I have over 2,000 bookmarks and 1 scroll of the touchpad does the entire height, all 2,156 bookmarks... Touchpad scrolling is way too sensitive. My laptop has a precision touchpad, maybe it's only an issue with precision touchpads? I don't have access to another laptop to check this out, sorry

Hey Will,
I tried reproducing this issue on the latest versions of Firefox Nightly 85.0a1 (2020-11-26), beta 84.0b4 and release 83.0 on a Lenovo Yoga device but the touchpad scrolling was done at the rate I wanted it and not instantaneous (I had over 100 bookmarks though). You could try changing the sensitivity as well : https://mcmw.abilitynet.org.uk/windows-10-slowing-down-your-touchpad .

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help and only import the bookmarks. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Flags: needinfo?(billdillensrevenge)

(In reply to Andrei Purice from comment #1)

Hey Will,
I tried reproducing this issue on the latest versions of Firefox Nightly 85.0a1 (2020-11-26), beta 84.0b4 and release 83.0 on a Lenovo Yoga device but the touchpad scrolling was done at the rate I wanted it and not instantaneous (I had over 100 bookmarks though). You could try changing the sensitivity as well : https://mcmw.abilitynet.org.uk/windows-10-slowing-down-your-touchpad .

Can you test the issue while in Safe Mode? You can find helpful info here : https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode .
Also a fresh new profile could help and only import the bookmarks. You can find more about creating a new profile here : https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile .
If possible, you can test this issue on the nightly build as well. Download the build from : https://www.mozilla.org/en-US/firefox/nightly/all/ .

Does your device have a precision touchpad? I suspect this might have to do with precision touchpads and the changes recently made to devices that have precision touchpads (the scrolling changes significantly in Firefox 83 or 82 on precision touchpad devices)

Flags: needinfo?(billdillensrevenge)

Hi,

I observed the same behavior on my Surface Pro Type Cover (I don't know if it has a Precision Touchpad).

The change occurred after I upgraded to Firefox 83 on Windows 10 (20H2).

The scrolling has visibly changed, going much "faster" than before, to the point that it looks "choppy" (but no choppy as in slow, choppy while being fast, if that makes any sense).

It is visible in the Library Window as stated by the OP, but on my computer it's also visible in other places, on websites. Facebook is one such website. And it also makes the web interface of my Synology NAS (DSM 6.2) painful to use, as the scrollbars in various "windows" (e.g. the File Manager) have become difficult to use.

I did not notice any changes regarding the scrolling elsewhere on my system, only in Firefox. Other apps and other browsers work as before.

Additional information : I tested the (touchpad) scrolling in different situations.

If I keep my Firefox 83 but start it in safe mode, the fast/choppy scrolling is still visible.

Then I installed different portable versions of Firefox. The behavior is still present in Firefox 85 nightly, BUT it is "slower" and much more usable in Firefox 82. So it is confirmed that the fast/choppy scrolling appeared in Firefox 83, at least on my computer.

Just to be clear, I'm not referring to smoothness or choppiness. I'm referring to the fact that I can scroll over 2000 bookmarks, the top to the bottom, with 1 swipe of the touchpad. That is quite a bug

Will , if you think that's a regression, then could you try to find a regression range in using for example mozregression( https://wiki.mozilla.org/Auto-tools/Projects/Mozregression )?

Flags: needinfo?(billdillensrevenge)

I don't know how to use that but I'm almost certain this issue was introduced when Firefox introduced some kind of support or changes for Windows devices that have precision touchpads, I think v82 or v83 or somewhere around there.

Flags: needinfo?(billdillensrevenge)

Yes this Lenovo does have a precision trackpad.

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Component: Untriaged → Layout: Scrolling and Overflow
Product: Firefox → Core

For those who are seeing this (and other reported changes in this bug), if you set in about:config

apz.allow_zooming=false
apz.windows.force_disable_direct_manipulation=true
apz.windows.use_direct_manipulation=false

then the problem goes away?

(In reply to Timothy Nikkel (:tnikkel) from comment #9)

For those who are seeing this (and other reported changes in this bug), if you set in about:config

apz.allow_zooming=false
apz.windows.force_disable_direct_manipulation=true
apz.windows.use_direct_manipulation=false

then the problem goes away?

Yes! It does. On the Surface Pro Type Cover. I only needed to change the first and the last one. Thanks for the tip.

Does it affect other behaviours in Firefox ?

Is this something that can be reversed in future version of Firefox, or would it mess things up for people that don't have the "fast scrolling" problem ?

Flipping those prefs the main result is that you won't be able to smooth pinch zoom pages in Firefox.

This is the first report that there is something wrong with the direct manipulation code we added, so we will look into it and try to fix it so that it is as good or better than it was before for everyone. You can temporarily use those prefs as a workaround.

Given that this doesn't affect everyone, and a workaround via prefs exists, marking as S3. Still, as a defect associated with an otherwise exciting new feature (pinch-zoom), it'd be nice to resolve as soon as possible, resources permitting.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Windows

The library list is a XUL tree, which scrolls in line-increments based on DOMMouseScroll events: https://searchfox.org/mozilla-central/rev/31ddf859c57e812878a5f817e4097efb06de4d97/toolkit/content/widgets/tree.js#793

I don't know if this will be useful information, but I was seeing the scrolling "bug" in the History and Bookmarks lists just like the OP, and also elsewhere in web pages, such as Synology's DSM 6.2 interface on my NAS. So I guess it's not limited to the library list. But that Synology interface could be using the same Javascript method to implement scrolling in its (fake) windows though, so maybe that's a lead.

Both are now fixed after changing the config values mentioned above.

Gentle ping, still seeing this in v88. I think for the devs to repro, they'll need to have a lot of bookmarks, like 1000 or more bookmarks. That's the only way you can really notice/repro it. If you only have 100 bookmarks, you probably wouldn't notice it. And ideally you'd have a Surface computer with a precision touchpad

Hmm, so looks like we populate the line mLineOrPageDeltaY field with pixel deltas. From bug 1653700, comment 6 I just copied what macos did. Unfortunately I seem to have made a mistake in reading the macos code, as seen here https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/widget/cocoa/nsChildView.mm#3278 according to the comment there the deltaX/deltaY hold line scroll information on the event, scrollingDeltaX/Y holds pixel scroll information. I must have seen deltaX/deltaY in the code and thought it held pixel scroll information. I'm not sure just yet exactly how to turn pixels into lines, I'll have to do some investigation.

Some code links to remind myself about the key points for when I can come back and fix this

dmanip sets the linedelta
https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/widget/windows/DirectManipulationOwner.cpp#512

delta accumulator for dommousescroll events
https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/dom/events/EventStateManager.h#893

where we dispatch these events from
https://searchfox.org/mozilla-central/rev/5e70cd673a0ba0ad19b662c1cf656e0823781596/dom/events/EventStateManager.cpp#2467

Flags: needinfo?(tnikkel)
Attached file wevdms.html

(In reply to Timothy Nikkel (:tnikkel) from comment #16)

I'm not sure just yet exactly how to turn pixels into lines, I'll have to do some investigation.

On macOS this happens via PanGestureInput::GetIntegerDeltaForEvent which has its own static accumulator.

(In reply to Markus Stange [:mstange] from comment #18)

(In reply to Timothy Nikkel (:tnikkel) from comment #16)

I'm not sure just yet exactly how to turn pixels into lines, I'll have to do some investigation.

On macOS this happens via PanGestureInput::GetIntegerDeltaForEvent which has its own static accumulator.

That turns an accumulation of floats which may be less than 1 in absolute value into integers. But according to the comment the floats we input to it are already lines.

Flags: needinfo?(tnikkel)
Flags: needinfo?(tnikkel)

Oh I see. You need a "line height in pixels" value. Ok, not sure how to handle that. Masayuki might have thoughts on this.

It can be solveed only in the content code since the line-height depends on the scroll target (e.g., line-height may depend on a11y settings). Therefore, EventStateManager and WheelHandlingUtils do it there. So, sending pixel values to APZ and APZ converts it in content is the right approach. Although I'm not sure whether this strict approach is reasonable for you.

Looks like we just have to set mIsNoLineOrPageDelta on the widget wheel events that we create from pan gesture inputs and then the event state manager will automatically fill in the line deltas for us. Mac knew the line deltas so it didn't need this.

Assignee: nobody → tnikkel
Status: NEW → ASSIGNED
Flags: needinfo?(tnikkel)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:tnikkel, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(tnikkel)
Flags: needinfo?(botond)
Flags: needinfo?(botond)
Flags: needinfo?(tnikkel)
Attachment #9220371 - Attachment description: Bug 1678771. Set mIsNoLineOrPageDelta on WidgetWheelEvents we create from PanGestureInput when we don't know the line scroll amount so EventStateManager will fill those in for us. r?botond → Bug 1678771. Set mIsNoLineOrPageDelta on WidgetWheelEvents we create from PanGestureInput when we don't know the line scroll amount so EventStateManager will fill those in for us.

So we can use it for sending pan gestures too.

Depends on D114358

We implement a new nsIDOMWindowUtils function sendNativeTouchpadPan to do this. It is only implemented on Windows here.

Depends on D122048

Pushed by tnikkel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/43d106dbffb2
Set mIsNoLineOrPageDelta on WidgetWheelEvents we create from PanGestureInput when we don't know the line scroll amount so EventStateManager will fill those in for us. r=botond
https://hg.mozilla.org/integration/autoland/rev/731c26701653
Rename TouchpadPinchPhase to TouchpadGesturePhase. r=hiro
https://hg.mozilla.org/integration/autoland/rev/8dc4ef909cec
Add test. r=hiro
Blocks: 1763121
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: