305896 - Side-scroll Vs. Forward/Back with button input 6/7

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[IdleGod]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20050729 Netscape/8.0.3.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20050729 Netscape/8.0.3.3

I have a mouse with both side-scroll and history buttons. Perhaps I'm not
looking hard enough, but the only option I find in Firefox is to change between
Side-scrolling and History navigation for the buttons 6/7. It would be nice to
see buttons 8/9 be mapped to forward/back since 6/7 are used as side-scroll in
most applications.

Reproducible: Always

Steps to Reproduce:
1. Scroll sideways
2. Use the back/forward buttons

Actual Results:  
It only does one or the other, and never both.

Expected Results:  
Scroll sideways, as well as navigate forward and back.

Sorry, my user-agent is misleading. I'm actually running Deer Park from Sunday
night at home where I experience this on multiple machines. I've been playing
with this on my new Apple Mighty Mouse. It has the nice analog side-scroll on
it. What I've found is that its more of a problem with the way X relates to
Firefox. What seemed to confuse me for the longest time was the way ZAxisMapping
worked. I thought it simply remapped the Z Axis button events to those you set.
In reality, those buttons weren't really buttons, but instead another axis. Most
mice that have side-scroll use buttons to acomplish this. Generally, most
applications (gimp, gaim, etc etc), all use the 'button' codes of 6 and 7 for
side scrolling, and the usual 4 5 for vertical. The vertical scroll works fine,
but the horiz scroll doesn't. For some reason, the default was set to
forward/back, but I hear that a backport has fixed that in the 1.0 tree, but not
yet in the 1.1 (1.5) tree. And thats all well in good. Playing with the X
driver, I found that XFree and XOrg lump the Z axis and the Wheel axis together,
so doing a ZAxisMapping of "4 5" will make both of those axis set to up/down
scroll. Now, the MM uses Wheel as up/down, and Z as left right, which causes a
rather annoying problem. I've managed to go through the X source and change the
Z to map along with the HWheel axis, which is a half-decent remedy for the
problem. But one other problem still remains, which I cant seem to solve. I use
another mouse along with my MM, and it has the side rocker for side scrolling.
That one defaults fine to 6/7, but it also has the side forward/back buttons. If
I change the preference to use the 'horizscroll' as side-side, I loose the
back/forward functionality. I've got a 3 day old build of firefox running at
home. Well, Deer Park Alpha 2 if you want to be technical. Generally, I use xev
only to check how it will be seen in the browser itself, or other apps, and use
evdev to check what actual instructions are being sent by the mouse so that I
can configure X correctly, which it currently is.

Comment 1

[Darren Salt]

<AOL> (wrt mapping buttons 8 and 9).

FWIW, I'm using X's evdev driver, pointing at a USB mouse with side buttons and a tiltable wheel (and a hacked kernel usbhid module to generate repeat events for REL_HWHEEL - don't rely on this!), with
	ZAxisMapping "4 5 6 7"
(which maps REL_WHEEL to 4 and 5 and REL_HWHEEL to 6 and 7) and a default X pointer buttons mapping.

Comment 2

[IdleGod]

Yes, but thats not the issue. I don't think I really made it all that clear what I was doing, and what I had accomplished, so I apologize. I have gotten the sidescrolling working, but I cant have side scrolling, and forward/back at the same time, without mapping mouse buttons to keystrokes. I believe that buttons 8/9 should be used for forward/back, instead of multiplexing it with 6/7 which are the standard side scroll button codes in Linux. 

Just for any future bug-scavangers, I got side scroll working with about:config, and the key (?) of mousewheel.horizscroll.withnokey.action. I believe I set it to 0, for scrolling, but I'm not entirely sure. The default on Linux (Not at that machine currently), is to use forward back, which (if 0 is scrolling) is 2. 

Comment 3

[Olivier Crête]

The patch at bug #305896 is a possible solution...

Comment 4

[Olivier Crête]

err I meant bug #355477

Comment 5

[[:Aleksej]]

Can anyone reproduce this bug with a current Firefox 2 or 3 build?

Comment 6

[Olivier Crête]

Yes, this is still reproducible in 2.0.0.6.

Comment 7

[[:Aleksej]]

It will not be fixed on 1.8 branch, so could you please test with a trunk build?
32-bit builds are here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Also, if it is there, feel free to check if your patch still applies, and possibly update it if it's not.

Comment 8

[Matěj Cepl]

this is duplicate of bug 412256, right?

Comment 9

[Mats Palmgren (inactive)]

Olivier Crête, this was fixed by bug 355477 for Firefox 3, right?

Comment 10

[Olivier Crête]

Yes, it was, now 6-7 are for scrolling and 8-9 are configurable.

Comment 11

[Mats Palmgren (inactive)]

Ok, I'm resolving it as fixed then.  Firefox 2 only takes security fixes at
this point so it wont be fixed there.

-> FIXED (by bug 355477)