508785 - [meta] Extremely high speed of mouse-wheel scrolling

Status: RESOLVED FIXED

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

Description

[Vladimir Kondratyev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090805 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090805 Minefield/3.6a1pre (.NET CLR 3.5.30729)

I've just install nightly build and mouse-wheel scrolling is extremely high. It's almost impossible to scroll by mouse-wheel.

Reproducible: Always

Comment 1

[Matthias Versen [:Matti]]

With which mouse driver ?
realted to bug 507222 ?

Comment 2

[Sylvain Pasche]

I think it's bug 508747. The default Windows setting is to scroll by 3 lines when using the mouse wheel. Now the mousewheel.withnokey.sysnumlines setting is used which scrolls by 6 lines, so that's twice as fast.

Comment 3

[Ria Klaassen (not reading all bugmail)]

I really wonder if this is a duplicate of bug 508747.
Reporter only seems to tell that he is not satisfied with the results of the changes by bug 462809, while bug 508747 is about the impossibility to set the browser to honor the system settings, because the pref mousewheel.withnokey.sysnumlines is broken. I guess the latter problem was not intentional, but the first problem is.
I expect however that everything will be fixed in one patch. :)

Comment 4

[Sylvain Pasche]

ok, I see. I was considering the single mouse wheel click case, which has now doubled in lines (using default settings). But with the new acceleration feature from bug 462809 that's now the expected behavior and this should be a WORKSFORME maybe.

Comment 5

[Dão Gottwald [:dao]]

(In reply to comment #4)
> I was considering the single mouse wheel click case

The reporter needs to clarify this.

Comment 6

[Vladimir Kondratyev]

I'm ready to provide any additional information, but unfortunately I do not understand what you are asking for. I'm using Windows XP, the mouse is Genius USB mouse with standard Windows driver.

I've just checked that when I scroll with mouse wheel on "one tic", page scrolls on 7 lines. I have a feeling that second tic scrolls even more lines. The final picture (my user experience) that FF scrolls 2-3 pages when I spin mouse wheel one time. This is new (and unwanted for me) behavior. If this is a "new feature" I'd like to ask to provide an option to switch it off.

I've asked several my colleges to try to use this build of FF and all said that it is unusable. This is just for your information.

Comment 7

[Sylvain Pasche]

Attachment: testcase

This pages prints the number of lines that were scrolled. It may be useful when experimenting with the scroll settings and comparing with other browsers (doesn't work in IE though).

Comment 8

[Masatoshi Kimura [:emk]]

(In reply to comment #7)
I've tested with some Windows browsers. Even Safari for Windows didn't provide a Alex's favorite acceleration. Instead Apple sells Mighty Mouse for Windows users.

Comment 9

[Dão Gottwald [:dao]]

I always get 5 lines in Safari 4 and 2 lines in Chrome 2. There doesn't seem to be any acceleration. I suspect the fact that they ignore the system setting (3 in my case) is due to a Webkit shortcoming.

IE8 seems to honor the system setting, although the testcase doesn't work there.

Comment 10

[Nochum Sossonko [:Natch]]

Firefox 3.5 and below: Scrolled by 2.85 lines (max 2.85)

Firefox 3.6: Scrolled by 5.7 lines (max 21.85)

That's on the same computes, different profiles.

That's a *huge* difference in behavior and makes it kind of feel like Chrome when it first came out (where you either saw the top or bottom of the page). I think the prefs just need to be tweaked a bit...

Comment 11

[Nochum Sossonko [:Natch]]

Attachment: testcase 2

Sylvian, I extended your testcase to read out all the scroll amounts encountered, plus it now works in IE (at least IE8).

Comment 12

[Radek 'sysKin' Czyz]

Interesting. Old firefox was scrolling just 2.85, 2.85, 2.85 etc.
Current trunk is 2.85, 2.85, 8.55, 11.4, 14.25...
The sequence doesn't look right even for this design* - I'd expect 1, 1, 2, 3, 4 but get 1, 1, 3, 4, 5. A soon as acceleration activates, it switches speed from non-accelerated values to accelerated ones, rather than starting acceleration at that point.

* I'd hate to spam this bug with off-topic comments but I really can't help myself: I said it before and I'll say it again, current acceleration model is an abomination from control theory perspective. Many of its problems can be easily predicted just by control theory tools.

Comment 13

[[not reading bugmail]]

After bug 513817 landed:

For super scroll, changing either:

mousewheel.acceleration.factor

didn't make a difference.

but if I change:
mousewheel.withnokey.sysnumlines = false

I get a slight difference.

If I change:
mousewheel.withnokey.sysnumlines = false
and
mousewheel.withnokey.numlines = 150+

it feels like accelerator..

Comment 14

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

fixed by bug fixed by bug 513817.

Comment 15

[[not reading bugmail]]

Forgot to mention also changing:
mousewheel.acceleration.start = 0

Found info on this blog: 
http://margaret.mit.edu/2009/08/making-firefox-feel-faster/