Open
Bug 1244607
Opened 8 years ago
Updated 2 years ago
Custom system mouse scroll settings are ignored
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
NEW
People
(Reporter: claritise, Unassigned)
References
()
Details
(Whiteboard: dom-triaged)
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160131030347 Steps to reproduce: Set the amount of lines scrolled to 11. Testing on a new profile shows Firefox scrolls about a line each time whereas IE scrolls the 11 lines. Expected results: Firefox should respect custom mouse scroll settings. Changing the amount of lines scrolled each time in mouse system settings does not correspond to a change in lines scrolled in Firefox. IE, Edge respect custom scroll settings.
Blocks: apz-desktop
Comment 1•8 years ago
|
||
I cannot reproduce this bug. Don't you test with Synaptics's touchpad? If so, we know that Synaptics's touchpad overrides system settings only when it's being used.
Comment 2•8 years ago
|
||
FYI: When you set both scroll amount (vertical and horizontal) to 3, Firefox makes the scrolling speed multiplied by 2. So, when you set the scroll amount to 11, the scroll amount is changed from 6 to 11. So, multiplied about only by 2.
I initiated the session with an actual mouse as initiating Firefox using the touchpad results in even worse scrolling. I think bug 1153156 exacerbated this issue. Getting the amount of lines scrolled in Firefox to 11 in practice would require changing the system settings to the amount of lines scrolled to ~23. However, setting the amount of lines scrolled to 23 results in substantially more amounts of lines scrolled in IE, Explorer and many other applications. This isn't a good user experience as many other applications scroll way too much. The amount of lines scrolled should be consistent throughout the system.
Comment 4•8 years ago
|
||
Could you confirm with this testcase with and without e10s? https://jsfiddle.net/d_toybox/x0e1uj3L/
Using system scroll settings to 11 vertical lines, the same scrolling behaviour is exhibited between e10s and non-e10s. One scroll within the first sub-container reaches number 14 at the top with both e10s and non-e10s. However, IE reaches 19 with one scroll. Scrolling parity is somewhat evident when changing the setting to one vertical screen at a time with Firefox getting to line 31 at the top of the first sub-container with one scroll and IE to line 29. Firefox's line scrolling behaviour is the odd one out as most Windows applications scroll identical amounts of lines as IE which should be used as the standard to compare against.
Updated•8 years ago
|
Component: Untriaged → Event Handling
Product: Firefox → Core
Comment 6•8 years ago
|
||
Name Firefox Version 47.0a1 Build ID 20160201030241 User Agent Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 I can reproduce - adding kats@mozilla.com to CC List as may relate to APZ
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•8 years ago
|
||
(In reply to ... from comment #5) > Using system scroll settings to 11 vertical lines, the same scrolling > behaviour is exhibited between e10s and non-e10s. Good, that's one of the fixes of bug 1153156. > One scroll within the first sub-container reaches number 14 at the top with > both e10s and non-e10s. Good. Although, I guess that your mouse is an expensive mouse which has smoother wheel. With such mouse, it's hard to test only 120 delta (one notch). So, scrolling 14 lines in the first scrollable element is our intentional behavior. Not ignored the prefs as the summary of this bug. > However, IE reaches 19 with one scroll. Okay. As far as I've tested, looks like that IE scrolls per line. I.e., depending on the font-size or line-height of the scrollable element (although, I cannot understand what they do exactly...). On the other hand, Google Chrome uses fixed value for any font-size scrollable elements. I.e., major 3 browsers use different approach. I believe that our current behavior isn't bad at least when line-height: 1.0;. > Scrolling parity is somewhat evident when changing the setting to one > vertical screen at a time with Firefox getting to line 31 at the top of the > first sub-container with one scroll and IE to line 29. Yeah, our page scroll scrolls page height - one line height because scrolling whole page may make some users confused in some cases. > Firefox's line scrolling behaviour is the odd one out as most Windows > applications scroll identical amounts of lines as IE which should be used as > the standard to compare against. What's the standard? What scroll amount is the best to you in the first scrollable element the second scrollable element?
Flags: needinfo?(claritise)
Comment 8•8 years ago
|
||
Anyway, this isn't a regression and not related to APZ. Dropping the dependency.
No longer blocks: apz-desktop
Comment 9•8 years ago
|
||
I tested with Wordpad on Win10, then, one notch of wheel causes exactly 3 lines, i.e., depending on the line height, not font size. So, it might be better to use line height instead of font size, though.
Reporter | ||
Comment 10•8 years ago
|
||
Unlike other applications, Firefox's scrolling behaviour seems more resistant and less influenced by the amount of lines scrolled system setting. I'm not sure of the exacts mechanics, Firefox just feels off and generally requires a few more scrolls to reach the same point as IE, Explorer, etc with one scroll especially when the amount of lines scrolled setting increases. Parity with IE would be ideal.
Flags: needinfo?(claritise)
Updated•8 years ago
|
Whiteboard: dom-triaged
Assignee | ||
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•