Closed Bug 508747 Opened 15 years ago Closed 15 years ago

mousewheel.withnokey.numlines overrides the OS setting

Categories

(Core :: Widget: Win32, defect, P2)

Product:
Core
Component:
Widget: Win32
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: dao, Unassigned)

References

Details

(Keywords: regression) 

On Windows, users can control the number of lines that should be scrolled in the control panel. It looks like bug 462809 made us stop honoring that pref and use mousewheel.withnokey.numlines instead.
Flags: blocking1.9.2?
The value of mousewheel.withnokey.sysnumlines seems ignored whatever it is.
>It looks like bug 462809 made us stop honoring that pref

This was a very intentional change (Chrome was doubling the default value making it "twice as fast")
I've been using Windows for a decade and knew about the OS pref, but intentionally kept it at three. I don't just want to scroll as fast as possible, but often also read while scrolling. Scrolling six lines makes this harder.

There's also the option to scroll one page. Users who activated that would now get slower scrolling.

Why do you think taking away that user choice and breaking consistency with other apps is the right thing to do?
I'd also like to point out that this seems to have been implemented the wrong way. Rather than ignoring mousewheel.withnokey.sysnumlines, it should have been set to false in firefox.js (except that I think it should actually default to true, honoring the OS setting).
We decided to override mousewheel.withnokey.sysnumlines in order to give the user control over the number of lines scrolled, as well as the acceleration behavior. If we chose not to do this, if the user set mousewheel.withnokey.sysnumlines to false, then the mousewheel.withnokey.numlines pref would override the delta calculated to include acceleration.

I think a solution could be to create another pref that scales the system value in case the user wants to scroll more lines per wheel click while maintaining acceleration. This would stop us from creating unexpected behavior.
I'm not sure I understand your proposal. Couldn't we just use the mousewheel.acceleration.* prefs to accelerate based on the system value?
>Why do you think taking away that user choice and breaking consistency with
>other apps is the right thing to do?

In terms of user choice, I think we are looking at a distribution where we are breaking .01% for the benefit of helping 99.9%.  Just because they could have modified the pref to improve their options doesn't mean they know about it, or actually did.  However there are probably ways to avoid breaking people who have customized, so ideally we actually can make everyone happy.

In terms of consistency, I think consistency as a UI goal is primarily about leaning how to interact with an application (symbols used, locations of controls, etc) so these are all higher level behaviors than a much more baked in and implicit thing like how scrolling moves.
(In reply to comment #8)
> In terms of user choice, I think we are looking at a distribution where we are
> breaking .01% for the benefit of helping 99.9%.  Just because they could have
> modified the pref to improve their options doesn't mean they know about it, or
> actually did.

Just because they didn't know about it doesn't mean they would have modified it. And I could have modified it but actually didn't. That I didn't change it to 6 doesn't make me part of your 99.9%, hopefully, since I think 3 is a better choice than 6. In other words, I'd challenge the "helping 99.9%" assessment. It's not clear at all to me that we're confusing or annoying a minority and helping a majority. Your number certainly is exaggerated, I'm just not sure how much.

I do think app-level acceleration of repeated scrolling events helps a majority and is a clear cost-benefit winner; it seems to be a useful feature that the OS lacks for no good reason, and that only advanced mouse drivers take care of.

> In terms of consistency, I think consistency as a UI goal is primarily about
> leaning how to interact with an application (symbols used, locations of
> controls, etc) so these are all higher level behaviors than a much more baked
> in and implicit thing like how scrolling moves.

I think it makes a lot of sense for scrolling to be consistent across Firefox, my e-mail client, my word processor and any other app with scrollable areas. Maybe this doesn't qualify as "consistency as a UI goal" (why, I haven't quite understood), but I think it's nonetheless a valid point on the costs side. Not a point that's necessarily more important than everything else (see my opinion about app-level acceleration), but still a valid one.
(In reply to comment #9)
> I do think app-level acceleration of repeated scrolling events helps a majority
> and is a clear cost-benefit winner; it seems to be a useful feature that the OS
> lacks for no good reason, and that only advanced mouse drivers take care of.

I don't think so. The patch of bug 462809 could break some Web applications and plug-in applications which use DOM mouse wheel events. E.g., the acceleration may obstruct some detail operations. The App scroll acceleration shouldn't be enabled in default settings. I believe that it's really the job of mouse drivers/utilities.
(In reply to comment #10)
> I don't think so. The patch of bug 462809 could break some Web applications and
> plug-in applications which use DOM mouse wheel events. E.g., the acceleration
> may obstruct some detail operations. The App scroll acceleration shouldn't be
> enabled in default settings. I believe that it's really the job of mouse
> drivers/utilities.
How exactly could it break some Web applications?  The acceleration isn't going to be kicking in in "detail operations", and other operating systems already do acceleration and those don't seem to break web applications.
I just said about the possibility. Gecko isn't only for Firefox. It's also a platform. So, such drastic event spec changes and the incompatibility with other web browsers shouldn't be good thing. (Please note that the users haven't changed any system settings, but the behavior is changed on Fx critically.)

And also I don't understand why you want to enable the wheel scrolling acceleration in App level (especially in default settings). Why don't you trust the system settings of the users and the mouse drives? The UI behaviors on each systems should be respected, but you tried to standardize them with your favorite behavior.
Could you please file separate bugs for any issues with acceleration? This bug is about the numlines change.
(In reply to comment #13)
> Could you please file separate bugs for any issues with acceleration? This bug
> is about the numlines change.

Ah, ok. Sorry.
(In reply to comment #14)
> (In reply to comment #13)
> > Could you please file separate bugs for any issues with acceleration? This bug
> > is about the numlines change.
> 
> Ah, ok. Sorry.

filed bug 509189.
How about:

1. respect the OS's numlines setting!!!

2. keep the acceleration, but reduce it significantly

3. Only start accelerating after the fist one or two mouse-wheel "turn-clicks" and stop is there is a delay of, say, 2 secs.

4. Focus on making smooth scrolling more ... smooth (e.g., by adding acceleration at the beginning of the scroll movement and deceleration at the end).
(In reply to comment #16)
> 3. Only start accelerating after the fist one or two mouse-wheel "turn-clicks"
> and stop ACCELERATING IF there is a delay of, say, 2 secs.

Damn typos. Sorry. :-[
(In reply to comment #16)
> How about:
> 
> 1. respect the OS's numlines setting!!!
> 
> 2. keep the acceleration, but reduce it significantly

I'd add to that that acceleration should only kick in if numlines is within a reasonable range (e.g. 1-6).
Blocks: 508785
(In reply to comment #3)
> This was a very intentional change (Chrome was doubling the default value
> making it "twice as fast")
Because Chrome doesn't provide an acceleration on Windows. If you stick with the current acceleration model, you don't have to double the initial speed. If you double the speed, it's an overkill to also provide an acceleration.
The default value of mousewheel.withnokey.numlines should be 1 if the acceleration is enabled. Otherwise most Windows users cannot control scrolling precisely. (see bug 509189 comment #17 for details.)
(In reply to comment #19)
> (In reply to comment #3)
> > This was a very intentional change (Chrome was doubling the default value
> > making it "twice as fast")
> Because Chrome doesn't provide an acceleration on Windows.

Not only does it not accelerate, I also can't confirm that it doubles the default value. Over here it actually  scroll two lines instead of three, although I guess that's a bug. Details in bug 508785 comment 9.
This bug should be fixed by bug 512235 landing. But note that there is the app level acceleration. See bug 509189.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
(In reply to comment #21)
> This bug should be fixed by bug 512235 landing.

Ok -- I'm setting status1.9.2 to beta1-fixed, then, to match that bug.
status1.9.2: --- → beta1-fixed
You need to log in before you can comment on or make changes to this bug.