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

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.

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...

*** Bug 235310 has been marked as a duplicate of this bug. ***

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!

*** 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...