1216934 - Mousewheel scroll animation velocity, momentum and decay should match OS

Status: RESOLVED DUPLICATE of bug 1418822

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

Description

[gordon]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Steps to reproduce:

Scroll any webpage using the mousewheel in windows 8 to 10


Actual results:

Firefox scrolls slowly and with less momentum compared to native scrolling in the OS.


Expected results:

The animation distance, velocity and decay should match the native OS behavior.

The difference is quite jarring, requiring many more mousewheel "flicks" to scroll the same distance as you would is say the Windows 10 "photos" app.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

I don't understand your report...

On Windows, scroll amount in pixels depends on the system settings and the line-height of the scroll target since native mouse wheel scroll speed settings is, how many *lines* should be scrolled per legacy mouse wheel's one notch. So, if the line-height of scrollable element is bigger, the scroll speed is faster. You can control the minimum line-height size with mousewheel.min_line_scroll_amount.

Additionally, Windows doesn't have momentum scroll events at least on Windows 8.x. So, if you feel momentum scroll with your mouse wheel (or touchpad?), it's emulated by your mouse or touchpad's utility.

Gecko supports high-resolution mouse wheel events. I guess this could conflict with Gecko's scroll animation. How do you feel if you disable general.smoothScroll.mouseWheel?

Comment 2

[gordon]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #1)

> On Windows, scroll amount in pixels depends on the system settings and the
> line-height of the scroll target since native mouse wheel scroll speed
> settings is, how many *lines* should be scrolled per legacy mouse wheel's
> one notch. So, if the line-height of scrollable element is bigger, the
> scroll speed is faster. You can control the minimum line-height size with
> mousewheel.min_line_scroll_amount.



> Additionally, Windows doesn't have momentum scroll events at least on
> Windows 8.x. So, if you feel momentum scroll with your mouse wheel (or
> touchpad?), it's emulated by your mouse or touchpad's utility.

I'm confused.  I have two laptops and three desktop PC's. All of which have smooth, inertial scrolling, as do all the desktops I work with and have done since windows 8. All have different mice.

Native Win32 apps have no mousewheel scroll animation whatsoever. But Native "Modern/Metro" apps in 8.x do as do all native "Universal" and "XAML" apps in Window 10.  With Microsoft gradually moving all native components of Windows over to its new design language almost all components of the OS now have this mousewheel scrolling animation.  The "Settings" app or "Cortana" are examples of native OS components which share this scrolling behaviour.

As described the easiest way to see the difference would be to open any "Modern" app in Windows 8.x or any "Universal" app in Windows 10. A single "click" or "pulse" of the mousewheel causes scrolling to animate to the next scrollpoint as defined by the systems mousewheel settings.  Scrolling the wheel more quickly causes momentum to be built up and the scroll increases in speed/distance smoothly and then decays when you no longer "pulse" the mousewheel.

Microsoft Edge follows exactly this behaviour and matches exactly the scrolling seen in the Windows 10 "News" app, "Photos" app, "Calendar" app, "Notification" centre and all others modern OS components or apps.

In contrast, scrolling in Firefox feels totally different and requires almost twice the number of mousewheel "pulses" in order to travel the same distance.

It is possible that the terminology I am using to describe the difference is incorrect.  If so please simply try any Webpage in Microsoft Edge versus Firefox.  Edge scrolls the same as native windows 10 apps.  Firefox does not.


> Gecko supports high-resolution mouse wheel events. I guess this could
> conflict with Gecko's scroll animation. How do you feel if you disable
> general.smoothScroll.mouseWheel?

Disabling this obviously removes the scroll animation altogether, making the disparity between Firefox and Native windows scrolling even greater.

Comment 3

[gordon]

Having done some further testing it appears that a single mousewheel "pulse" in firefox travels approximately 2 - 2.5 times less distance than a single pulse in native Windows 10 applications.

Comment 4

[gordon]

Incidentally, Chrome travels the roughly the correct distance from a single "pulse", but of course has no scrolling animation whatsoever.

Comment 5

[gordon]

Attachment: Single mousewheel pulse distance traveled

This image shows the distance traveled by a single mousewheel "pulse" across all three browsers.  Firefox, Chrome, Edge.  Even forgetting the huge difference in scrolling animations, Firefox requires 2-3 more effort with the mousewheel to scroll the same distance as the other two.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

> Native Win32 apps have no mousewheel scroll animation whatsoever. But Native "Modern/Metro" apps
> in 8.x do as do all native "Universal" and "XAML" apps in Window 10.

That must be implemented by application level in desktop apps and probably when modern apps need to implement scrollable area themselves. general.smoothScroll.mouseWheel enables the feature of smooth scrolling on Gecko. The native behavior should be same as the behavior when this is disabled.

So, I don't understand what you claim as a problem for smooth scrolling.

> In contrast, scrolling in Firefox feels totally different and requires almost twice the number 
> of mousewheel "pulses" in order to travel the same distance.

What's the registry values of WheelScrollChars and WheelScrollLines in HKEY_CURRENT_USER\Control Panel\Desktop? When both of them are 3 (Windows default), we override the scrolling speed as 6-6 only on the root scrollable element.

We cannot ignore system settings since some mouse utilities implement acceleration, momentum scroll, etc. Therefore, if we make scrolling speed twice than now, in some environment, the scroll speed may become too fast. We've already try that at Firefox 4 (IIRC), then, we decide that we should just care only the environments whose scroll speed isn't customized by the user nor mouse utility.

Additionally, on my environment, Win10 with MX Master (Logitech), both scrolling speed are 3, when I turn mouse wheel one notch, the scroll amount is similar to Google Chrome (and Firefox is larger to scroll).

Comment 7

[Markus Stange [:mstange]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> > Native Win32 apps have no mousewheel scroll animation whatsoever. But Native "Modern/Metro" apps
> > in 8.x do as do all native "Universal" and "XAML" apps in Window 10.
> 
> That must be implemented by application level in desktop apps and probably
> when modern apps need to implement scrollable area themselves.

Apparently there's the Direct Manipulation framework for system-implemented scroll areas these days:
https://www.reddit.com/r/windows/comments/1hky29/precision_touchpads_the_future_of_touchpads_on/caw3obp

Comment 8

[gordon]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)

> That must be implemented by application level in desktop apps and probably
> when modern apps need to implement scrollable area themselves.
> general.smoothScroll.mouseWheel enables the feature of smooth scrolling on
> Gecko. The native behavior should be same as the behavior when this is
> disabled.
> 
> So, I don't understand what you claim as a problem for smooth scrolling.

To me the problem is quite simple.  Scrolling with the mousewheel in Windows 8-10 has a totally different speed/line-height/acceleration/momentum than in Firefox.  In Windows 10, this is all standardised.  In Windows 10's next update there will literally be next to no user facing Win32 components left, therefore, even though Firefox is built using Win32 would it not make sense to try and match the scrolling behaviour with that of the host OS?

Furthermore the Windows 8 "modern" and Windows 10 "XAML" do not appear to implement smooth scrolling at an application level.  I believe the behaviour is built in to the design language and as such every app now being released for Windows 10 has exactly the same mousewheel scroll behaviour.

Right now everytime I scroll on my PC I get one scrolling behaviour in Firefox, and a different scrolling behaviour for literally everything else I do. I understand Firefox has to implement smooth scrolling itself due to being Win32 but I cannot fathom why Mozilla would not want to keep in unison with the parent OS.  This is fine on Windows 7 as all UI components were Win32 and therefore matched Firefox.  Now the two different experiences feel extremely jarring.



> What's the registry values of WheelScrollChars and WheelScrollLines in
> HKEY_CURRENT_USER\Control Panel\Desktop? When both of them are 3 (Windows
> default), we override the scrolling speed as 6-6 only on the root scrollable
> element.

Both are set at 3.

> We cannot ignore system settings since some mouse utilities implement
> acceleration, momentum scroll, etc. Therefore, if we make scrolling speed
> twice than now, in some environment, the scroll speed may become too fast.
> We've already try that at Firefox 4 (IIRC), then, we decide that we should
> just care only the environments whose scroll speed isn't customized by the
> user nor mouse utility.

I'm not saying that system settings should be ignored, quite the reverse.  I simply feel that the behaviour in Firefox should mirror the experience in the host OS.  Which is probably more jarring in Windows 10 due to its apps using "XAML" rather than Win32 almost exclusively.
 
> Additionally, on my environment, Win10 with MX Master (Logitech), both
> scrolling speed are 3, when I turn mouse wheel one notch, the scroll amount
> is similar to Google Chrome (and Firefox is larger to scroll).

I've just reinstalled nightly and funnily enough the distance traveled per notch is now much closer to Chrome, so it appears I was coming up against some other bug regarding the mousewheel, and a refresh sorted out.

But that still does not change the nature of this bug, which is about the difference between the behaviour of scrolling in Windows 10 versus Firefox.  I fear that failing to mirror this behaviour is going to potentially cause people to move to Microsoft Edge, as there the experience feels natural and in sync with the OS.

Comment 9

[gordon]

(In reply to Markus Stange [:mstange] from comment #7)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> > > Native Win32 apps have no mousewheel scroll animation whatsoever. But Native "Modern/Metro" apps
> > > in 8.x do as do all native "Universal" and "XAML" apps in Window 10.
> > 
> > That must be implemented by application level in desktop apps and probably
> > when modern apps need to implement scrollable area themselves.
> 
> Apparently there's the Direct Manipulation framework for system-implemented
> scroll areas these days:
> https://www.reddit.com/r/windows/comments/1hky29/
> precision_touchpads_the_future_of_touchpads_on/caw3obp

Exactly...Thanks for chiming in Markus.  According to that MS engineer applications (including Win32 ones like Firefox) can choose to implement the DManip just as IE and Edge does.  Would this not be preferable to the current application level smooth scroll present in Firefox?  To me it makes sense to standardise Firefox with the rest of the OS.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away: 6/25-6/28)]

(In reply to Markus Stange [:mstange] from comment #7)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> > > Native Win32 apps have no mousewheel scroll animation whatsoever. But Native "Modern/Metro" apps
> > > in 8.x do as do all native "Universal" and "XAML" apps in Window 10.
> > 
> > That must be implemented by application level in desktop apps and probably
> > when modern apps need to implement scrollable area themselves.
> 
> Apparently there's the Direct Manipulation framework for system-implemented
> scroll areas these days:
> https://www.reddit.com/r/windows/comments/1hky29/
> precision_touchpads_the_future_of_touchpads_on/caw3obp

Ah, but can we use that? It looks like to access compositor? If so, after handling WM_MOUSE*WHEEL (for dispatching DOM events and deciding the target scrollable elemnt), we send the message to it and the contents scrolled automatically?

Anyway, looks like we need a lot of work like TSF:
https://msdn.microsoft.com/en-US/library/windows/desktop/hh446966%28v=vs.85%29.aspx

Comment 11

[Markus Stange [:mstange]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #10)
> (In reply to Markus Stange [:mstange] from comment #7)
> > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #6)
> > > > Native Win32 apps have no mousewheel scroll animation whatsoever. But Native "Modern/Metro" apps
> > > > in 8.x do as do all native "Universal" and "XAML" apps in Window 10.
> > > 
> > > That must be implemented by application level in desktop apps and probably
> > > when modern apps need to implement scrollable area themselves.
> > 
> > Apparently there's the Direct Manipulation framework for system-implemented
> > scroll areas these days:
> > https://www.reddit.com/r/windows/comments/1hky29/
> > precision_touchpads_the_future_of_touchpads_on/caw3obp
> 
> Ah, but can we use that? It looks like to access compositor?

That question is still open - we absolutely need to be able to do our own compositing. In bug 1199807 Jeff looked into it a little but didn't get very far.

Comment 12

[Jim Mathies [:jimm]]

Gordon, are you still seeing this?

Comment 13

[gordon]

The difference is still present, yes.  It's not that I don't like the current Firefox decay/speed settings. It's just that they are noticeably different from the host OS.l, in this case Windows 10.

The most noticeable difference is when scrolling a scrollable element, and not the document root. In this case scrolling is incredible slow, it is around half the speed of scrolling the body for some reason.  I find it literally unbearable, and this is my main reason for having to use chrome as my main browser, despite having a strong preference for Firefox.

Comment 14

[Botond Ballo [:botond]]

What is the relationship between this bug and bug 1217715? Is this a generalization of bug 1217715 (covering aspects other than just speed)?

Comment 15

[Kartikaya Gupta (email:[e-mail])]

Bug 1217715 is specifically about the inconsistency between the root scroller and the non-root scrollers. This one seems to be more about the physics of the root scroller not matching that of the OS default. Using Direct Manipulation might help with that but I don't know enough about it to really say.

Comment 16

[Will]

https://bugzilla.mozilla.org/show_bug.cgi?id=1418822

Comment 17

[Kartikaya Gupta (email:[e-mail])]

I'm going to forward-dupe this to bug 1418822 since there's more work on that bug, and the underlying complaint seems to be the same in both bugs, that mousewheel-scrolling on Windows is slower in Firefox when compared to Chrome/Edge.