509189 - The application level mouse wheel scrolling acceleration should be disabled in default settings

Status: RESOLVED FIXED

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

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

By bug 462809, the application level wheel scrolling acceleration was implemented. But there are some issues:

1. The accelerating should be a job of mouse driver or utilities.

The mouse wheel scrolling acceleration isn't standardized on Windows. It's implemented by mouse drivers or the utilities. For the non-supported mouse driver users, the application level implementation would help them, it's great things I think. However, some people can disable the acceleration in the mouse settings. Then, we should not use the acceleration. Unfortunately, we cannot know the settings on Windows.

2. The accelerating changes the DOM mouse wheel event specification on Fx.

The current acceleration is implemented in nsWindow of Windows. And it increases the delta value of the event. It also changes the DOM event's value. So, the acceleration could break some Web applications or plugin applications. So, I wonder why the acceleration wasn't implemented in ESM, then, the DOM event behaviors are not changed but we could change the behavior...

I recommend that we should disable the acceleration in default settings. The application level acceleration can confuse some users who don't use/like it. And also the most users who like the acceleration should use the mouse driver's acceleration already.

Even if we enable the settings in default, the users should be able to disable it in option dialog easily (like autoscrolling).

# And I write a worry here. The patch of bug 462809 wasn't reviewed by Win32 widget owner or its peers even though it's a big change.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Additionally, I've looked a mouse which doesn't have "wheel", it has "switch" instead. The switch can be tilted to ahead or to this side. And the users continuously tilt it until the scrolling is finished. In such device, the application level acceleration may create serious regression. The acceleration mechanism depends on the "wheel" device's characteristic.

Comment 2

[Dão Gottwald [:dao]]

(In reply to comment #0)
> # And I write a worry here. The patch of bug 462809 wasn't reviewed by Win32
> widget owner or its peers even though it's a big change.

vlad is a /widget peer. The patch should have been super-reviewed, though.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #2)
> (In reply to comment #0)
> > # And I write a worry here. The patch of bug 462809 wasn't reviewed by Win32
> > widget owner or its peers even though it's a big change.
> 
> vlad is a /widget peer. The patch should have been super-reviewed, though.

I think that it's really "Widget - Windows" area, not "Widget"...
http://www.mozilla.org/owners.html#widget-windows

Comment 4

[Shawn Wilsher :sdwilsh]

(In reply to comment #2)
> vlad is a /widget peer. The patch should have been super-reviewed, though.
There was no API change, so sr wouldn't be needed per the new tree-wide policy.

Comment 5

[Dão Gottwald [:dao]]

Overriding native behavior and exposing that change to web content seems sr-worthy to me. I don't think that should cause problems for web content, but   Masayuki Nakano seems to disagree.

IMO the patch should have been rejected because of the mousewheel.withnokey.numlines / mousewheel.withnokey.sysnumlines issue, but I don't really care whether as part of a peer review, super-review or ui-review. I also really wonder if Beltzner was fully aware of what the patch does and how it does it; the review comment seems to indicate that we could fix up things by adjusting prefs, which isn't quite the case.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #4)
> (In reply to comment #2)
> > vlad is a /widget peer. The patch should have been super-reviewed, though.
> There was no API change, so sr wouldn't be needed per the new tree-wide policy.

Oh, I didn't know the changes of sr condition. However, changing the values in ns*Event makes module wide impact. E.g., it changes the actual behavior of content (including ESM), web contents and the automated tests. So, I think the change should be in "All changes that affect how code modules interact". I believe that the patch needed sr.

Comment 7

[Peter Lairo]

I think the developers will insist on having acceleration, so I would suggest that the acceleration *amount* should be reduced significantly.

Comment 8

[Alex Faaborg [:faaborg] (Firefox UX)]

>The current acceleration is implemented in nsWindow of Windows. And it
>increases the delta value of the event. It also changes the DOM event's value.
>So, the acceleration could break some Web applications or plugin applications.

Given that the same Web applications are expected to work in Firefox and Safari on OS X, and there the OS is providing an accelerated scrolling model, why would introducing an acceleration model on Windows break Web applications?  While we did change something fundamental, wouldn't any effected applications already be effected when Apple changed the behavior for OS X, and we automatically picked it up?  Is there a different approach that would produce the same behavior but would be a cleaner implementation?

>The accelerating should be a job of mouse driver or utilities.

I agree that being able to change this at the OS level would be ideal, but that approach significantly limits our ability to improve Firefox on Windows, and limits our ability to differentiate against other the Web browsers on Windows.

>Even if we enable the settings in default, the users should be able to disable
>it in option dialog easily (like autoscrolling).

I'm pretty sure I agree, especially if we continue to see pretty divergent feedback on how much people like or dislike the change.

>The application level acceleration can confuse some users
>who don't use/like it.

I think the most logical approach is to choose the default state based on the relative size of the two user populations, as opposed to simply the existence of a contingent of dissatisfied users. We need to take into account both benefits and costs, and not purely costs.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #8)
> >The current acceleration is implemented in nsWindow of Windows. And it
> >increases the delta value of the event. It also changes the DOM event's value.
> >So, the acceleration could break some Web applications or plugin applications.
> 
> Given that the same Web applications are expected to work in Firefox and Safari
> on OS X, and there the OS is providing an accelerated scrolling model, why
> would introducing an acceleration model on Windows break Web applications? 

Firefox can be able to use intranet applications too. There are some applications which don't target to several environments. If we change such event model by our logic, we can never make great "platform".

And also, some web application may change the behavior between platforms.

> While we did change something fundamental, wouldn't any effected applications
> already be effected when Apple changed the behavior for OS X, and we
> automatically picked it up?  Is there a different approach that would produce
> the same behavior but would be a cleaner implementation?

I think that we don't need to think the platform level behavior changes.

> >Even if we enable the settings in default, the users should be able to disable
> >it in option dialog easily (like autoscrolling).
> 
> I'm pretty sure I agree, especially if we continue to see pretty divergent
> feedback on how much people like or dislike the change.
> 
> >The application level acceleration can confuse some users
> >who don't use/like it.
> 
> I think the most logical approach is to choose the default state based on the
> relative size of the two user populations, as opposed to simply the existence
> of a contingent of dissatisfied users. We need to take into account both
> benefits and costs, and not purely costs.

I doubt it. Why can the MacOS X's behavior make most Windows users happy? Windows and MacOS X has different behaviors. They are culture and they makes each OS's user's experience for many years. But the current trunk build denies the differences between OSs (and also the mouse driver's settings).

The disabling in default setting doesn't make any objections of the users. And also the most acceleration needed users should already have been using it which is provided by the mouse driver. The enable setting is only helping a few people, instead of many people who don't like the app level acceleration (including doubled accelerated users), I believe.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> Firefox can be able to use intranet applications too.

oops, I meant Firefox can be used as intranet applications too.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>Why can the MacOS X's behavior make most Windows users happy?

Because flicking the scroll wheel 40 times to get to the bottom of a long page is tiresome.  Independent of all of the connotations related to something being a "OS X behavior" or "Windows behavior," having an acceleration based scrolling model makes navigating through documents considerably easier after a momentary period of adjustment.

I believe that Microsoft's approach of only including the software solution of an acceleration model with particular physical mice could simply be explained by their hardware division trying to add incentives for users to buy more expensive mice.

>including doubled accelerated users

This is a significant problem that we will need to try to address, I've filed the follow up bug 509651

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #11)
> I believe that Microsoft's approach of only including the software solution of
> an acceleration model with particular physical mice could simply be explained
> by their hardware division trying to add incentives for users to buy more
> expensive mice.

I don't think so. There are non-mouse wheel devices, see comment 1. Softwares should not assume that the device individuality is always same as the major device of now.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #11)
> >Why can the MacOS X's behavior make most Windows users happy?
> 
> Because flicking the scroll wheel 40 times to get to the bottom of a long page
> is tiresome.  Independent of all of the connotations related to something being
> a "OS X behavior" or "Windows behavior," having an acceleration based scrolling
> model makes navigating through documents considerably easier after a momentary
> period of adjustment.

And if my memory is correct, the MS's mouse driver accelerate the scrolling in default settings. I'm not sure other mouse diver's default settings. But if others are same, the flicking is not more important problem for the users than that they love the non-accelerating behavior.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #8)
> >So, the acceleration could break some Web applications or plugin applications.
> 
> Given that the same Web applications are expected to work in Firefox and Safari
> on OS X, and there the OS is providing an accelerated scrolling model, why
> would introducing an acceleration model on Windows break Web applications?

Do we in fact use the same acceleration model as OS X? I.e. does OS X increase number of lines rather than the event rate?

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

in reply to comment #12
>There are non-mouse wheel devices

It's my understanding that acceleration provides the user with more control (assuming it is working correctly) regardless of the nature of the physical hardware.  It also should have nice accessibility benefits since it overall requires less total movement.

in reply to comment #14
>Do we in fact use the same acceleration model as OS X? I.e. does OS X increase
>number of lines rather than the event rate?

Margaret may know the answer (this is what I was worried about above, where we actually would be introducing a totally new behavior to the Web).

Comment 16

[Masatoshi Kimura [:emk]]

(In reply to comment #11)
> Independent of all of the connotations related to something being
> a "OS X behavior" or "Windows behavior," having an acceleration based scrolling
> model makes navigating through documents considerably easier after a momentary
> period of adjustment.

On Mac, all apps will have a consistent acceleration behavior because the mouse driver provides it.
Windows users, however, will get a *worse* experience because they will have to switch the mind only when they are operating Firefox.
Your approach will not succeed unless you can provide a consistent behavior to all apps. Apparently it is not a Web browser's job.

Comment 17

[Masatoshi Kimura [:emk]]

OK, I touched Mac in the shop and understood what Alex said.
On Mac, Scroll Ball rotates smoothly. Then you can scroll one line (or even sub-line) at a time by rotating the Scroll Ball slowly.
On Windows, however, most mouse wheel can't rotate smoothly. So wheel event will always have delta whose value is multiples of WHEEL_DELTA (120). Only a few Windows mice support sub-WHEEL_DELTA scroll. As a result, most users can't scroll under six lines at a time. It's far from Mac users' experience.
> It's my understanding that acceleration provides the user with more control
> (assuming it is working correctly) regardless of the nature of the physical
> hardware.
It is not possible at all for most Windows users. This is not a matter of familiarity but an unfortunate hardware restriction. An only solution is buying a mouse which supports a smooth rotate.
> I believe that Microsoft's approach of only including the software solution of
> an acceleration model with particular physical mice could simply be explained
> by their hardware division trying to add incentives for users to buy more
> expensive mice.
Actually you are forcing most Windows users to buy a more expensive mouse.
Moreover, an acceleration model on Mac is also bound to particular hardware (that is, Mighty Mouse). Yes, this acceleration is specific to Mighty Mouse.
It's just that Mac is shipped with Mighty Mouse by default.
Windows is shipped with Internet Explorer, so any users shall familiar with a behavior of Internet Explorer, no?

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

I don't think this blocks, per se; we want to fix the problems (as expressed by the other bugs that do block) and we want to have a final decision, but for that we should discuss things in dev-apps-firefox.

We want to have proper mouse acceleration at some point; right now we can't get it right, so we will turn it off by default, but the way this bug is expressed makes it sound like we'd never turn it on again, and I don't think that's the case.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

temporally, fixed by bug 513817. However, if the user (or the mouse driver) didn't customize the scrolling speed, the root views of each document are scrolled doubled speed.