543511 - In Firefox 3.6 Intellipoint mouse scrolling acceleration is disabled downwards, acceleration still works upwards.

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[urlug]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

In Firefox 3.6 Intellipoint mouse scrolling acceleration is disabled downwards, acceleration still works upwards. In Firefox 3.5.7 (which I reverted back to) doesn't have this problem, nor does Internet Explorer, Opera, Windows Explorer or any program, I can scroll up and down with Intellipoint's acceleration normally.

I have tried using MS Intellipoint drivers 5.5 and 7.0 both with same outcome.

I read that 3.6 implemented some sort of mouse scrolling acceleration (mousewheel.acceleration.start) of its own but it is set to -1 (disabled) by default because it is still in developing stage(?). It doesn't matter if I put -1, 0, 1, 2, 3 or any number on it Intellipoint scroll acceleration still doesn't work downwards but Firefox 3.6's own acceleration works though it will be multiplied upwards because it has both FF's and Intellipoint's acceleration on.

It's VERY annoying to scroll pages up and down when upward scrolling is much faster than downward. I know I can disable the Intellipoint scrolling acceleration but then I'd lose it on all other programs like Windows Explorer plus Intellipoint's scroll acceleration feels better and more natural than FF 3.6's (for now).

My mouse is Microsoft Wheel Mouse Optical (PS/2) with Intellipoint 7.0

Reproducible: Always

Steps to Reproduce:
1. Install FF 3.6
2. Use MS Wheel Mouse Optical (or any MS mouse) + Intellipoint (5.5 ->) 7.0, make sure scrolling acceleration is on (should be by default)
3. Scroll a long page down fast and then up as fast you just did. The scrolling is much slower downwards than updwards due to disabled (downward) Intellipoint scrolling acceleration.
Actual Results:  
the scrolling was slower downwards

Expected Results:  
have acceleration when scrolling down also

Default theme used.
I tried the test in safe mode disabling addons but with the same outcome.

Comment 1

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

Sounds like bug 527853.

Comment 2

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

Attachment: Patch v1.0

Maybe, this is the cause.

I'll prepare the test build.

Comment 3

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

testbuilds:

trunk:
http://build.mozilla.org/tryserver-builds/[e-mail]-bug527853_v1.0

1.9.2 branch (Fx3.6):
http://build.mozilla.org/tryserver-builds/[e-mail]-bug527853_v1.0_1.9.2

urlug: would you test on the build?

Comment 4

[urlug]

Thanks for your effort.
I set the following line (in Firefox 3.6 stable) mousewheel.system_scroll_override_on_root_content.enabled to false (like you suggested in bug #527853) and the normal (Intellipoint) scrolling acceleration now works both ways, just like in 3.5.7.

btw I tried your 3.6.2 pre and 3.7a and they worked in a sense because in them the scrolling was not faster upwards, it was the same speed both ways, though the Intellipoint scrolling acceleration was disabled both directions because mousewheel.system_scroll_override_on_root_content.enabled is set to true by default. Changed it to false and Intellipoint acceleration worked fine like in 3.6 stable after changing the same setting.

Comment 5

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

Don't mark as resolved. Any problems are not fixed.

Thank you for your testing. I'll post a new patch which may fix the problem in default settings.

Comment 6

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

Attachment: Patch v2.0

I think that we should do nothing if the given delta value is larger than the limitation delta value of our computation.

The test build will be coming.

Comment 7

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

http://build.mozilla.org/tryserver-builds/[e-mail]-bug543511_v2.0_1.9.2

Would you retest on this build?

Comment 8

[urlug]

Yep, that (v2.0_1.9.2) worked. Intellipoint scrolling acceleration worked normally both ways, even when the mousewheel.system_scroll_override_on_root_content.enabled was true (by default).

Comment 9

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

Comment on attachment 424833 [details] [diff] [review]
Patch v2.0

Thank you, urlug.

Roc, would you review this?

There are two bugs:
1. When given delta is negative, I checked the computed value with positive limitation value.
2. Even when the given delta is larger than the limitation value, I ignored the thing. We shouldn't return smaller delta value than the given value.

Comment 10

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

http://hg.mozilla.org/mozilla-central/rev/48fde4aa4334

Comment 11

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

Comment on attachment 424833 [details] [diff] [review]
Patch v2.0

Simple mistake, and this affects some users' experience. If an user uses faster scroll settings or driver level acceleration, we are failing to compute the wheel scrolling speed. So, we're overriding the system scrolling speed by wrong computed speed.

Comment 12

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

Comment on attachment 424833 [details] [diff] [review]
Patch v2.0

a1922=beltzner

Comment 13

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

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6717ac6eafa4

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I do not have a MS mouse and Intellipoint isn't installed. Urlug, would you be able to run a test against the Firefox 3.6.2 candidate build to check if it is fixed in the final release? Thanks

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.2-candidates/build3/win32/en-US/

Comment 15

[urlug]

I updated to the official 3.6.2 version and it works just fine.
mousewheel.system_scroll_override_on_root_content.enabled set to true (default)

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks for your feedback Urlug! Let's mark it verified fixed then.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Kyle, can you please add at least the build identifier when marking a bug as verified? Have you used a 3.7 build?

Comment 18

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I haven't tested it myself.  I assumed 

(In reply to comment #16)
> Let's mark it verified fixed then.

meant you intended to mark it as verified.

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

> (In reply to comment #16)
> > Let's mark it verified fixed then.
> 
> meant you intended to mark it as verified.

I did with the appropriate keyword. Setting the status to verified implies testing with the version given in target milestone.

Comment 20

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #19)
> > (In reply to comment #16)
> > > Let's mark it verified fixed then.
> > 
> > meant you intended to mark it as verified.
> 
> I did with the appropriate keyword. Setting the status to verified implies
> testing with the version given in target milestone.

Ah, was not aware of the distinction.  Thanks!