1263746 - large elements scroll far too slowly with mousewheel

Status: RESOLVED DUPLICATE of bug 1217715

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[gordonrankin82]

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

Steps to reproduce:

Open any webpage with a scrolling element that is 'not' the root document


Actual results:

Mousewheel scrolling is unbearable slow


Expected results:

Mousewheel scrolling speed should match the document root scroll speed, native OS scroll speed, and the scroll speed of all other browsers.

My understanding is that for the root document, a mousewheel scroll-override is active, that in effect doubles the mousewheel 'step' amount.  This brings Firefox mousewheel scrolling roughly in line with Google Chrome.

However, the override is not active on normal, 'non-root' scrollable elements.

Plainly put, mouswheel scrolling behaviour and speed should match the host OS and other browsers, in all circumstances.  As it stands attempting to scroll anything other than the root document in Firefox with the mousewheel is just unbearable and completely different to the mousewheel scrolling experience found throughout windows 10 in general and all other browsers.

As a rough guide to what I am experiencing, in the Windows 10 'News' application if I perform a single fast 'flick' and allow the scroll momentum to continue, I will end end up scrolling around 3 full viewport height's worth.

In contrast, with the same force/speed of a mousewheel 'flick' in Firefox, I end up travelling less than 1/6th of the viewport.  The difference is so drastic as to make Firefox unusable.

If we forget for a moment that there may be differences in scroll momentum/physics, If I scroll a single 'tick' of my mousewheel, the step amount or distance traveled appears to be around twice as far in all native Windows 10 applications and all over browsers.

As a developer there are so many use-cases for large, scrollable elements that it seems extremely odd for Firefox to be providing such a dramatically different experience to the behavior that is present everywhere else throughout the Host OS and other browsers.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Any chance for a minimal testcase here?

Since on my machines FF's wheel handling feels currently smoother and usually a bit faster than in other browsers. (Linux and Windows, at least.)

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Attachment: a testcase

This is a testcase I was using. Just some <pre style="overflow: scroll;"> element with lots of text inside it.

Comment 3

[gordonrankin82]

(In reply to Olli Pettay [:smaug] from comment #2)
> Created attachment 8741002 [details]
> a testcase
> 
> This is a testcase I was using. Just some <pre style="overflow: scroll;">
> element with lots of text inside it.

Using your testcase the issue is evident if you scroll a single mousewheel 'tick'.

From the top of the scrollable <div>, scroll the mousewheel a single 'tick'.  These are the results for each browser:

- Firefox: 3 lines (* License, v. 2.0.)
- Chrome: 7 lines (#include "mozilla/dom/ContentChild.h")
- Edge: 6 Lines (#include "mozilla/dom/ContentBridgeChild.h")

Obviously this is simply the 'step' amount.  If we look at the smooth scroll physics/momentum the difference between the three browsers becomes even greater when 'flicking' the mousewheel.  Of course, this is difficult to quantify so the 'step' amount serves as the best comparison.

If the same content is placed in the root document, then the number of lines traveled on a single mousewheel 'tick' matches Chrome.

The scroll behavior doesn't feel as bad in your minimal testcase since the scrollable div is small.  There are many use cases to have larger scrollable elements.  For instance, imagine a webmail/email client with two separate, scrollable, full window height panes.  The Email content is attached to the root document and scrolls at 6 lines per mousewheel tick, but the message list pane to it's left would only scroll at 3 lines per mousewheel tick.  Ultimately this creates a hugely inconsistent experience and would not take place in any other browser, or in any other native application, on any OS.

I will make a testcase version of the above mentioned email client.

Comment 4

[gordonrankin82]

Attachment: Email client example testcase

As requested, here is a minimal testcase of a webmail client as described in my previous comment.

As you can see the left scrollable pane scrolls half the distance compared to the one on the right.

This is extremely frustrating behavior for users as it does not apply to any other application or browser.