Closed Bug 231718 Opened 19 years ago Closed 17 years ago

Horizontal mouse wheel doesn't work properly since 1.6

Categories

(Core :: Preferences: Backend, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: sbrabec, Assigned: mozilla)

References

Details

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031011 Galeon/1.3.10
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Standard binding of dual wheel mouse used by GTK+ 2.x is:
Button 4-5 vertical scrolling
Button 6-7 horizontal scrolling

Mozilla was working in the same way up to 1.5.
Since 1.6 it seems that buttons 6, 7 are binded to text clipping, which is not
much useful.

There is no configure option in Mouse wheel section to define behavior.

Reproducible: Always

Steps to Reproduce:
Have a dual wheel mouse and page with horizontal scroll bar.
Move with horizontal roller.
Actual Results:  
Page is not scrolling and takes a text clip instead. (Tested with Dell laptop
with synaptics driver). Short rolling takes word, longer whole line, even longer
nothing.

Expected Results:  
Horizontal scrolling.

Mozilla 1.4 and 1.5 works OK.

Maybe related bugs: bug 228764, bug 229481, bug 176458.
*** Bug 249124 has been marked as a duplicate of this bug. ***
It seems to work for me when I add
pref("mousewheel.horizscroll.withnokey.action",0);
pref("mousewheel.horizscroll.withnokey.numlines",1);
pref("mousewheel.horizscroll.withnokey.sysnumlines",true);
to my user.js

Strange that I have to tweak mozilla to work like all other applications by default.
I've experienced this problem (horizontal scrolling events make browser go
forward/back instead).  My suggestion is to change the default configuration
like so:

mousewheel.horizscroll.withcontrolkey.action = 3;
mousewheel.horizscroll.withcontrolkey.numlines = 1;
mousewheel.horizscroll.withcontrolkey.sysnumlines = true;

mousewheel.horizscroll.withnokey.action = 0;
mousewheel.horizscroll.withnokey.numlines = 1;
mousewheel.horizscroll.withnokey.sysnumlines = true;

mousewheel.horizscroll.withshiftkey.action = 1;
mousewheel.horizscroll.withshiftkey.numlines = 1;
mousewheel.horizscroll.withshiftkey.sysnumlines = true;

The previous defaults were to have each of these sections act like
mousewheel.horizscoll.withaltkey.* .  This change will mirror the settings for
mousewheel.with* .
Hmm, following bug 241646 the defaults for horizscroll were all changed to not
work, this would imply that the suggested change breaks something on Windows,
although I cannot see how. I just mirrored the defaults from mousewheel.with* to
mousewheel.horizscroll.with* on OS/2 and it works fine. Having them disabled by
default also seems to cause spurious problems like bug 261435.
->Prefs backend, OS=All
Status: UNCONFIRMED → NEW
Component: GFX: Gtk → Preferences: Backend
Ever confirmed: true
OS: Linux → All
Attachment #160815 - Flags: review?(bryner)
Attachment #160815 - Flags: superreview?(roc)
Attachment #160815 - Flags: superreview?(roc) → superreview+
Comment on attachment 160815 [details] [diff] [review]
Mirror normal mousewheel prefs onto horizscroll prefs

The current settings for the horizscroll prefs are to do history back/forward,
as in bug 64485.  On Linux, there's no way that I'm aware of for us to tell
whether mouse buttons 6-7 correspond to horizontal scroll or to back/forward
buttons on the mouse (on Windows, the mouse driver takes care of this
distinction and we get an entirely different message for back/forward).

So, I'm not sure what the best way is for us to handle this conflict. 
Certainly for operating systems that get an unambiguous horizontal scroll
message (mac and os2), the current pref defaults are wrong.  For Linux, we're
forced to either make a choice or create a pref, unless someone knows a clever
way to query X for details about the mouse hardware.

Minusing this patch as is, we need a better plan than reverting 64485.
Attachment #160815 - Flags: review?(bryner) → review-
OK, all.js is already preprocessed. So we can make the default settings
platform dependent. This patch now activates horizontal scrolling by default on
Windows, MacOSX, and OS/2. Not to double too many lines I defined an extra
variable. While this will obviously not help the Linux users who originally
opened this bug it is a workaround to make horizontal scrolling work again in
the default configuration on the platforms that differ between the different
event messages.

While I am here, I want to question the decision from bug 64485. You basically
work around shortcomings of X in an application (Mozilla) to activate a feature
(back/forward buttons on a mouse) which I think is used by less users than
could make use of horizontal scrolling (those with switchable scrollwheel or
two scrollwheels). At least in all the places I have been, no Linux users have
a back/forward button mouse while many (nearly all?) users have other mice...
Dupe of bug 236257?
I would say it's the other way around. But it might be important that bug 236257
is for Windows, don't know about the driver situation there. Here we also
already have a patch...
Comment on attachment 163215 [details] [diff] [review]
Make the horizscroll behaviour platform dependent

Ups, completely forgot to ask for reviews again...
Attachment #163215 - Flags: superreview?(roc)
Attachment #163215 - Flags: review?(bryner)
Attachment #163215 - Flags: superreview?(roc) → superreview?(bryner)
*** Bug 235310 has been marked as a duplicate of this bug. ***
Attachment #163215 - Flags: superreview?(bryner)
Attachment #163215 - Flags: superreview+
Attachment #163215 - Flags: review?(bryner)
Attachment #163215 - Flags: review+
Attachment #160815 - Attachment is obsolete: true
Comment on attachment 163215 [details] [diff] [review]
Make the horizscroll behaviour platform dependent

Great, thanks for the reviews. Is anybody willing to check this in?
checked in. Thanks!
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 303537 has been marked as a duplicate of this bug. ***
*** Bug 282564 has been marked as a duplicate of this bug. ***
See also bug 303913, for porting this fix to the Firefox 1.0.x branch.
*** Bug 316592 has been marked as a duplicate of this bug. ***
Sorry, just want to assign to me to let me find the bugs I worked on...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Assignee: blizzard → mozilla
Status: ASSIGNED → NEW
Status: NEW → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.