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

Steps to reproduce:

1. Zoom in using the pinch-to-zoom gesture. (This is a different kind of zoom than what happens when ctrl+plus is pressed. When zooming using the touchpad gesture, the page maintains its dimensions, the browser window just shows a smaller part of the screen.)
2. Scroll around with the touchpad.

Actual results:

Scrolling is way too sensitive.

Expected results:

Scrolling shouldn't be too sensitive. Essentially, I think Firefox should divide the scroll distance by the current zoom level, so that zooming in to 2x means that each scroll event moves 1/2 as far.

As it is, scrolling always seems to scroll some number of "CSS pixels". It should've scrolled some number of physical display pixels, meaning that the number of "CSS pixels" per scroll event should be lower when zoomed farther in.

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Thanks for filing. This is one of the issues mentioned in bug 1682974, which is an area we're hoping to make improvements in in the near future. I'll hang this bug off of that one for now.

This might be related to something specific in your configuration. Possibly the hardware you are using. Would you be willing to share the hardware you are using?

I am also curious how fast the actual scrolling looks. Martin, would you mind uploading a screen recording? And it would be really appreciate to upload another screen recordings on Chrome during scrolling to compare with the difference. Thanks!

Ok, so this is a bit interesting. Here's a video of a scrolling experiment: https://p.mort.coffee/ArE.webm (I'll attach it to the bug as well for posterity). One full touchpad swipe scrolls around 5600 CSS pixels without zooming in, and a bit over 1100 CSS pixels fully zoomed in. I originally assumed that it didn't take the zoom level into account at all, but that doesn't seem to be the case.

When fully zoomed in, 100 CSS pixels is 1000 screen pixels, while when not zoomed in, 100 CSS pixels is 100 screen pixels. So fully zooming in is a 10x zoom, so we would expect a fully zoomed in full touchpad swipe to move 5600/10=560 CSS pixels if a fully zoomed out swipe moves 5600 CSS pixels. However, a fully zoomed in touchpad swipe moves around 5600/5=1120 CSS pixels. So essentially, when fully zoomed in, scrolling is 2x as sensitive as one would expect, considering the scroll sensitivity when not zoomed in.

Not sure if it is related but let see my issue with Google Maps

I compare Brave then Firefox by zoom step by step.
You will see scrolling on Brave is very smooth.
Firefox is jumping when scrolling and Google Maps is not usable 😂

Video recording
https://vimeo.com/665269974

@Pongsatorn it's better to file a separate bug for that, as even though the gesture is the same, in the Google Maps case the zoom is being handled by the site so the cause could be different.

If you execute |window.devicePixelRatio| in the console what value do you get? Based on your comment I'm guessing it'll be 2, but I want to confirm.

It was quite hard to tell whether scroll sensitivity is depending on zoom level or not. I actually created a similar test case in the comment 6 video and tried to see if it's more sensitive on 10x zoom level on my Windows laptop and my Macbook. But I can't tell whether it's sensitive or not. So I decided to write a mochitest to measure the scroll distances caused by a series of pan gesture events both 1x zoom and 10x zoom levels. The results on Windows and Mac are reasonable.

So, I am mostly sure this is specific for Linux, specifically this if (aEvent.mDeltaType == PanGestureInput::PANDELTA_PAGE block. Unfortunately there's no machinery to send pan gesture events in test on Linux yet.

Add a missing comma.

And rename the function to promiseNativePanScroll so that we can reuse this
function as an encapsulated function for pan scrolling tests on desktops.

Depends on D140599

Depends on D140600

I did upload a series of patches to add a mochitest to measure scroll distance by pan gestures on all desktop platforms. (One of the patches (D140599) adds an ability to send native pan gesture events on Linux).

With these, I can confirm that the scroll distance on Linux is different, depending on the zoom level. As I suspected in comment 10, the difference comes from this scrollUnits calculation. From the calculation;

    auto scrollUnitHeight = std::min(std::pow(pageScrollSize.height, 2.0 / 3.0),
                                     pageScrollSize.height / 2.0) *             
                            zoom.scale;

Given that the scroll frame's scroll port height is 1000px in CSS unit, then the scrollUnitHeight will be 1000^(2/3) * 1.0 = 100 on 1x zoom level, the scrollUnitHeight will be 100^(2/3) * 10.0 = 215.44... on 10x zoom level. That shows us exactly the fact that scroll speed on 10x zoom level is approximately 2x faster what Martin commented in comment 5.

(Note that the above scrollUnitHeight calculation is not accurate what we do actually, since the pageScrollSize is calculated by ScrollFrameHelper::GetPageScrollAmount and it also factors zoom level into the calculation, so the scrollUnitHeight calculation is actually a bit more complicated.)

Anyway, the calculation was originally added in bug 1213601, it looks like it's intentional. CCing greg who implemented touchpad scrolling on Linux in bug 1213601.

No longer blocking bug 1682974 since that is specific to Windows and this bug is specific to Linux