Closed Bug 508785 Opened 15 years ago Closed 15 years ago

[meta] Extremely high speed of mouse-wheel scrolling


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

Windows XP



Tracking Status
status1.9.2 --- beta1-fixed


(Reporter: vladimirkondratyev, Assigned: masayuki)



(Keywords: meta, regression)


(2 files)

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
Blocks: 462809
Version: unspecified → Trunk
With which mouse driver ?
realted to bug 507222 ?
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.
Closed: 15 years ago
Resolution: --- → DUPLICATE
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. :)
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.
(In reply to comment #4)
> I was considering the single mouse wheel click case

The reporter needs to clarify this.
Component: General → Widget: Win32
Keywords: regression
Product: Firefox → Core
QA Contact: general → win32
Resolution: DUPLICATE → ---
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.
Depends on: 508747
Ever confirmed: true
Flags: blocking1.9.2?
Depends on: 509189
Attached file 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).
Depends on: 509651
Flags: blocking1.9.2?
Keywords: meta
(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.
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.
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...
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Attached file testcase 2
Sylvian, I extended your testcase to read out all the scroll amounts encountered, plus it now works in IE (at least IE8).
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.
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: blocking1.9.2+
Priority: -- → P2
After bug 513817 landed:

For super scroll, changing either:


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
mousewheel.withnokey.numlines = 150+

it feels like accelerator..
fixed by bug fixed by bug 513817.
Assignee: nobody → masayuki
Closed: 15 years ago15 years ago
Component: Widget: Win32 → Event Handling
QA Contact: win32 → events
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Forgot to mention also changing:
mousewheel.acceleration.start = 0

Found info on this blog:
Component: Event Handling → User events and focus handling
Summary: Extremely high speed of mouse-wheel scrolling → [meta] Extremely high speed of mouse-wheel scrolling
You need to log in before you can comment on or make changes to this bug.