Open Bug 207665 Opened 21 years ago Updated 2 years ago

mousewheel + mouse movement goes forward in history

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

People

(Reporter: rlmoser, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529

When scrolling with the mouse wheel (Microsoft Intellimouse Optical), if the
mouse moves, the browser loads the next page in the browser history.  If there
are no more pages forward in the history, it loads the previous page.  Occurs
even when no modifier keys are set to make the mouse wheel move in the history list.

Reproducible: Always

Steps to Reproduce:
1. Have more than one page in your history. 
2. Scroll mouse wheel while moving mouse.
Actual Results:  
If pages were present forward in the history, next page in history was loaded. 
If no pages forward, previous page in history loaded.

Expected Results:  
Scroll current page & move cursor.
After some further testing, this appears to be related to my KVM switch. 
Immediately after a reboot, this behavior is not observed.  After switching to a
different computer on my KVM switch, and then back to the original, the behavior
occurs.
This also occurs on my system.  The steps to reproduce listed by the original
poster are accurate.  I have no problem with mouse wheel behavior in any other
applications on any of my other computers.  I am using Mozilla 1.4 Final on
Windows Server 2003 with a Microsoft Intellimouse Optical attached to a Linksys
PS2KVM4 (4 Port PS2 KVM Switch).
I have the same problem with Moz 1.4 Final, Win 2000, and a Logitech optical
mouse attached to an ARP DATACON Master View Switch model CS-142.
The Linux version of Moz 1.4, with exactly the same hardware, does not show this
effect.
FYI, the bug still exists in 1.5 beta.  Same hardware, operating system,
symptoms, and steps to reproduce as in previous comment.
Flags: blocking1.5?
Some more additional info:

I originally thought that our KVMs might be causing some weird key press events
to occur (specifically a CTRL, ALT, or SHIFT) while the mouse wheel is
scrolling.  I tested this theory out by setting all the modifier keys under the
mouse wheel prefs to perform the same action.

It doesn't matter if the pref is set to scroll x lines (or system default), page
up/down, or increase/decrease font size; mouse scrolls still cause the
forward/backwards behavior IN ADDITION TO the correct behavior.

To me, this sounds like a misplaced case or if statement in the code somewhere.
 I don't know how this would relate to everyone having KVM switches.  I'm asking
friends without KVMs to test this out (it doesn't seem to occur on my system
when my KVM is not attached).

Since I'm back at school and have my bandwidth back, I'm going to start syncing
with CVS and trying to track down this bug;  I really want to see it fixed by 1.5.

I downloaded last night's nightly source (20030901) and built it (it still
contains the bug).  Unfortunately, by the time I got the build properly set up,
I was too tired to dig too far into it but the best candidate for the file
containing the bug seems to be mozilla/widget/src/windows/nsWindow.cpp because
it appears to contain the Windows implementation of the mouse scroll event (and
so far this appears to be a Windows-only bug).  That's where I'm beginning my
search.

If you have any thoughts about this bug, feel free to contact me at
http://dcowern.at.tulane.edu (take out the http:// and replace the .at. with @).
Bryner, seen anything like this recently?
Assignee: saari → bryner
not going to hold 1.5 for this.
Flags: blocking1.5? → blocking1.5-
Bad news for this bug.  I finally got sick of this bug and decided to start
using Opera again.  I first tried the latest beta (7.20b10) and was surprised to
see similar behavior.  It does not always go backwards and forwards but the
titlebar almost always flickers to show the title of the previous/next page in
the browsing history.  It appears Opera has implemented some sort of trap
against this behavior but it does not always work.

Seeking to further investigate, I clicked the wheel.  Opera said it detected a
shift+scroll button click.  This is consistent with my first theory as to what
is causing this bug.  It appears that my KVM is incorrectly sending the scroll
button scroll and click signals to the PS/2 port as shift+scrolls and shift+clicks.

I think the reason only Opera and Mozilla are affected is because they're the
only applications I use that have separate behavior for shift+scroll and
shift+clicks (for example, IE, OpenOffice, mIRC, etc do not exhibit weird
scrolling behaviors).  Does anyone know of a program that will intercept
key/mouse events and display those events in real time?  I'd like to investigate
this.

Even though it appears to be a problem in our hardware, it also appears that
there is a problem somewhere in Mozilla because my mouse whell preferences are
set such that No Modifier Key, Alt, Ctrl, and Shift should all scroll my page by
the system default so -- under my setup at least -- it should not matter if my
KVM is sending a shift key along with my scroll.

I will be receiving a Cybex 4-port SwitchView in a few days.  I will test this
bug with it and post my results.
This is definitely a hardware problem and not a Mozilla problem.  I received my
new KVM switch today (Avocent/Cybex 4-port SwitchView) and cannot reproduce the bug.

Prior to receiving the new switch, I changed my sample rate from 100
reports/second down to 40 reports per second thinking that maybe my mouse was
sending data to the KVM faster than it could process it and was causing a race
condition.  The unusual behavior continuted even with the slower sample rate.

I also wrote a simple Visual Basic program to test my hypothesis about
extraneous keypress events being sent.  Whenever the keydown event fires, my app
displays the ascii keycode of the key pressed.  Pressing either of the shift
keys produced correct results.  Scrolling my mouse produced nothing.

My guess is that my old Linksys was sending signals that were slightly out of
spec that then caused some erroneous Windows messages to be sent.  This problem
will probably affect any application that allows the mouse scroll behavior to be
modified by other keypresses (as shown by the Opera case).  Short of pulling the
data right off the PS/2 bus, I don't know how to test this theory.
I just wanted to report that this bug does not seem to affect Mozilla Firebird 0.7.
I can confirm this.  I have the same problem with both 1.6 & 1.7.  I have a
Linksys 4-port KVM switch and a Microsoft optical Intellimouse.
I also have this problem (Mozilla v1.7 & Firefox 1.0) and I also use a KVM
switcher, switchinf from one PC running Linux and the other running Windows XP.  

In about:config it make no difference if I ensure that none of my
mousewheel.*.action options are set to 2 (history option).

The only difference I see is that it only scrolls forward when there is a page
in history to go forward to. If I am at the last history position (forward
button disabled) it does not attempt to scroll backwards.

I can't understand why this isn't high priority, it makes the browser too
infuriating to use.
Wanted to add a vote for this bug.  It is pretty major IMHO.

The bug exists on Firefox 1.5 on Linux.
I just upgraded to firefox 1.5 and the first thing I noticed is this major regression for me. 1.4.x used to work fine.

The mouse scrollwheel no longer scrolls up/down the page by default.
Instead it does history forward/back.

More details:
- I'm on Linux Mandrake 10.2 with Xorg and KDE so this doesn't seem to be Windows2000 specific.

- Keyboard scrolling (using arrow keys) works fine

- Mouse-wheel causes forward-back in history instead of scrolling

- Changing the 'about:config'  mousewheel.withnokey.action from 0 (default) to any of 1, 2, 3 doesn't seem to make any difference.

In short there's no way I can see to override the unwanted and unexpected  default behavior.

I think the priority needs to be increased here.  It is a pretty big usabilty problem at least for me.

Going back to previous version. Sorry.

Update: my problem is solved.  It had nothing to do with Firefox.
Please accept my apologies for my previous update to this bug.

Here's what I learned. Hope fully it will help others.

1) Use 'xev' to verify whether the mouse actually generates events to X11 (I use X.org) if not, it is not a Firefox problem.  In my case there were no events when I scrolled the mousewheel up/down in the square area on the 'xev' window. This made it clear that the problem is in X itself.

2) The combination that works for me in /etc/X11/XF86Config (linked from xorg.conf) is the following. Note that the comments on what works and what doesn't refer to "Logitech Cordless Mouseman Optical" and may not apply to other hardware:

Section "InputDevice"
        Identifier "Mouse1"
        Driver "mouse"

        # "Auto" or "ExplorerPS/2" don't recognize lower-left (thumb) mouse
        #  button.
        # "MouseManPlusPS/2" recognizes thumb button, but not scroll-wheel :(
        #   Option "Protocol" "Auto"
        #   Option "Protocol" "ExplorerPS/2"
        #   Option "Protocol" "MouseManPlusPS/2"
        # "ImPS/2" recognizes both!
        Option "Protocol" "ImPS/2"
        Option "Device" "/dev/mouse"
        # "5" may be sufficient here, "6" or "7" don't make any difference
        Option "Buttons" "6"
        Option "ZAxisMapping" "4 5"
EndSection

The "ZAxisMapping" is important, I saw several suggestions on the web to use "6 7" and this doesn't work with my mouse. It causes it to stop generating scroll events on scoll-wheel up/down.  "4 5" works.

Sorry again for the previous report.  I blamed Firefox 1.5 prematurely.









I have the same behavior on Gentoo Linux with a Micro Innovations scroll wheel mouse plugged in via PS/2 port on the latest Deer Park ebuild.  I am not using a KVM switch.
Assignee: bryner → events
QA Contact: desale → ian
I am experiencing the page forward/back scroll bug since firefox 2.0.0.6 upgrade.  I am also using a 4 port Belkin omni cube kvm which I have been using this kvm for 2 years with no scrolling issues in firefox prior to 2.0.0.6.  
mouse=wireless intellimouse Explorer 2.0  

The mouse problem occurs in Firefox 2.0.0.6 on XP Pro service pack 2 (up to date on security updates).  

The mouse problem does not occur on my slackware 11 box running KDE 3.5.7 and Firefox 2.0.0.6 which is also using the same 4 port kvm.  
Same problem. Using Firefox 3.0 with microsoft basic optical mouse combined with a KVM switch and I experience it both in Windows XP SP3 and Fedora 9. 
The problem was not there in Firefox ver 2.
Assignee: events → nobody
QA Contact: ian → events
Help! This awful bug just doesn't let me use my firefox now!!!
My firefox version is firefox 13!!!
Why are those mousewheel options in about:config NOT at all affecting firefox's 13 behavior?!?!?
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.