Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 420294 - Side mouse buttons no longer work as back and forward
: Side mouse buttons no longer work as back and forward
: relnote, user-doc-complete
Product: Core
Classification: Components
Component: Widget: Gtk (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 422365 424722 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-02-29 06:28 PST by Ash Heron
Modified: 2008-06-18 03:11 PDT (History)
20 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Ash Heron 2008-02-29 06:28:17 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021721 Firefox/3.0b4pre (Swiftfox)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021721 Firefox/3.0b4pre (Swiftfox)

With the latest 3.0 beta 4, side mouse buttons 6 & 7 are no longer work back and forward.
My buttons as always are mapped to "ButtonMapping" "1 2 3 6 7".

Reproducible: Always

Steps to Reproduce:
1.Open Firefox 3.0 beta 4
2.Click mouse buttons 6 & 7

Actual Results:  

Expected Results:  
Should be mapped to back and forward like before.

Using Razer DeathAdder mouse.

Xorg.conf excerpt: 

Section "InputDevice"
    Identifier     "Configured Mouse"
    Driver         "mouse"
    Option         "Name" "Razer DeathAdder"
    Option         "Vendor" "Razer"
    Option         "CorePointer"
    Option         "Protocol" "ExplorerPS/2"
    Option         "ZAxisMapping" "4 5"
    Option         "Device" "/dev/input/mice"
    Option         "Buttons" "7"
    Option         "ButtonMapping" "1 2 3 6 7"
    Option         "Resolution" "900"
    Option         "SampleRate" "1000"
Comment 1 Reed Loden [:reed] (use needinfo?) 2008-02-29 08:35:49 PST
I've heard numerous complaints about this lately. What did we do that broke this?
Comment 2 Michael Monreal [:monreal] 2008-02-29 10:37:13 PST
Don't know the bug number but there has been a bug about mapping some mouse buttons differently. My understanding was that it would actually fix THIS issue...

I have seen some (seemingly) random page skips while scrolling with the wheel some days ago but I cannot reproduce this now. My first guess was that it was also related to the bug I mentioned before.
Comment 3 Julien "_FrnchFrgg_" RIVAUD 2008-02-29 13:34:22 PST
I thought 4 & 5 where the vertical wheel (vertical scroll), 6 & 7 the horizontal one, and 8 & 9 were the extended buttons that have recently been mapped to back and forward ?

In firefox 2, 6 & 7 are wrongly mapped to back/forward (compare to what does GIMP, for instance, where 6 & 7 do a horizontal scroll), and in Firefox 3, they are correctly mapped to horizontal scroll. Not that the Firefox 2 behaviour is really annoying whith touchpads with two scrollbars, since it is far too easy to touch a little the horizontal scroll zone, and change the current page...
Comment 4 Michael Ventnor 2008-02-29 13:43:32 PST
_FrnchFrgg_ is right, we now correctly treat 6 and 7 as the horizontal scroll so we don't cripple people with touchpads that can scroll in any direction. For back and forward you should be using 8 & 9, which was fixed a little while ago.
Comment 5 Julien "_FrnchFrgg_" RIVAUD 2008-02-29 16:54:52 PST
See bug 355477
Comment 6 Ash Heron 2008-03-01 11:09:59 PST
Mapping buttons to 8 & 9 does not work. 

Multiple logitech and razer mice have two side buttons "on the left side" (the mice geared towards right handed users). These two side buttons are mapped to 6 & 7, for left handed mice users there are ampidextrous mice which have symetrical buttons on the other side. Mice like the razer copperhead and diamondback for example which have buttons 8 & 9 mapped to the two buttons on the right hand side of the mouse, with my old diamondback (ampidextrous) mouse 8 & 9 was mapped to vertical scroll.

So this leaves right handed mice users without 9 buttons unable to use their two side buttons as back and forward, which is quite _alot_ of users.

For me 6 & 7 are not currently mapped to horizontal scroll eather, they are unresponsive in firefox.
Comment 7 Ash Heron 2008-03-01 11:13:15 PST
Sorry in my last comment there is a error, what I meant to say was "with my old diamondback (ampidextrous) mouse 8 & 9 was mapped to horizontal scroll."
Comment 8 Julien "_FrnchFrgg_" RIVAUD 2008-03-01 15:49:52 PST
Ash, you can map your mouse buttons to any value with Xorg, IIRC. I'm pretty sure there's a thing to do in xorg.conf to make your side buttons trigger 8 & 9, even if you don't have 9 buttons. Here we mimick what GTK does, so with gtk apps you'd have the same problem.
Comment 9 Mike Faith 2008-03-02 18:07:38 PST
Can you please post an example xorg.conf so that we may see how to get the side mouse buttons working with firefox?
Comment 10 Julien "_FrnchFrgg_" RIVAUD 2008-03-03 07:10:36 PST
Taken from :

> Newer versions of XOrg contain a new variable for mapping mouse buttons from
> within xorg.conf. XOrg 7.0 starts by assigning 11 buttons, taking 4 5 6 7 as
> scroll buttons and leaving 7 physical buttons. There is no need to use xmodmap 
> to modify what buttons point where as there seems to be a new option for that 
> within xorg.conf, "ButtonMapping". In fact, without any editing xorg.conf 
> seems to have the following default:
> Option "ButtonMapping" "1 2 3 8 9 10 11" 
> The syntax is as follows:
> File: /etc/X11/xorg.conf
> Section "InputDevice"
>       Identifier  "Mouse1"
>       Driver      "mouse"
>       Option      "Device" "/dev/input/mice"
>       Option      "Protocol" "auto"
>       Option      "ButtonMapping" "1 2 3 6 7"
> EndSection

It doesn't seem to work with the evdev driver, according to this page (and to the evdev manpage). You can still resort to xmodmap or xinput equivalents, though. I don't know why your Xorg doesn't default to using 8 & 9, but you can try to explicitely tell it to use "ButtonMapping" "1 2 3 8 9 10 11".
Comment 11 Jeffrey Baker 2008-03-05 16:51:45 PST
With a Logitech 7-button mouse I now must do this:

xmodmap -e "pointer = 1 2 3 4 5 9 8"

I don't know why 9 and 8 are reversed.  Perhaps I like forward and backward mapped opposite to prevailing preference.
Comment 12 Julien "_FrnchFrgg_" RIVAUD 2008-03-06 10:11:32 PST
Can we close this bug as INVALID ?
Comment 13 Jeffrey Baker 2008-03-06 10:16:29 PST
I'd leave it open until this is definitely in the release notes.  Perhaps reassign?
Comment 14 Reed Loden [:reed] (use needinfo?) 2008-03-06 10:54:58 PST
beltzner, please relnote this.
Comment 15 Reed Loden [:reed] (use needinfo?) 2008-03-06 10:57:15 PST
(In reply to comment #14)
> beltzner, please relnote this.

I added this to -- somebody that's been better following this bug may wish to re-write my wording there.
Comment 16 Alex Umrysh 2008-03-11 17:22:20 PDT
I came upon a solution to this problem that has worked for my synaptics touchpad with no modification to the xorg.conf file.
go to about:config and search for mousewheel.horizscroll.withnokey
set withnokey.action to 2 (1 will use horizontal scrolling i believe(like if your mouse had a left-right scroll wheel and not buttons), not sure what 0 does, maybe 0 is just disabled)
set withnokey.numlines to -1
setting the numlines pref to 1 will reverse the normal mouse scrolling.
the withnokey.sysnumlines does something, but I am not sure what.
if anyone has any more information on these preferences it might be helpful.
Comment 17 Alex Umrysh 2008-03-11 17:25:56 PDT
looks like the sysnumlines boolean should be set to false.  just to recap.
mousewheel.horizscroll.withnokey.action = 2
mousewheel.horizscroll.withnokey.numlines = -1
mousewheel.horizscroll.withnokey.sysnumlines = false
Comment 18 Sylvain Pasche 2008-03-16 15:40:45 PDT
*** Bug 422365 has been marked as a duplicate of this bug. ***
Comment 19 Sylvain Pasche 2008-03-28 15:56:00 PDT
*** Bug 424722 has been marked as a duplicate of this bug. ***
Comment 20 haarp 2008-03-29 06:45:38 PDT
Putting back/forward on 8/9 may be the right thing to do. However, many people need to change their Xorg configs for this to work. Doing this breaks about -every- single application for me that uses the side buttons. Wine apps don't recognize it anymore, and native games see it as mouse6 or not at all.

I had to create a wrapper script that undoes the xmodmap changes, starts my game, and redoes them just for mouse buttons to work properly.

Therefore I'd like to request a patch to undo this or at least make it an option to choose which mouse button to set back/forward too. This would take care of the whole problem once and for all. It would suffice to make this changeable in about:config
Comment 21 Sylvain Pasche 2008-03-29 08:25:16 PDT
It is changeable in about:config. If you have back/forward mapped to 6/7 respectively, just use the settings in comment 17.
Comment 22 haarp 2008-03-29 09:07:22 PDT
Ah, I see, thanks. I thought this was only related to scrolling, whereas it defines the actions of mouse6 and 7. Maybe the name of these strings should be changed to something more recognizable.
Comment 23 Chris Ilias [:cilias] 2008-05-01 06:56:20 PDT
Comment 24 George Montana Harkin 2008-05-19 13:27:45 PDT
Can the required about:config changes be made default for Linux installs?
Comment 25 Julien "_FrnchFrgg_" RIVAUD 2008-05-19 15:02:55 PDT
George: The behaviour of current Firefox 3 is consistent with other GTK apps. Why would we want to revert to the old behaviour ? If you prefer the old, you can still get it by tweaking about:config, but the real fix for your problem would probably be to get Xorg use the correct button numbers for your mouse: 4 5 and 6 7 are supposed to correspond to scroll wheels according to Xorg documentation, so if your buttons aren't related to scroll they should be mapped as 8 and 9.

See comment 10
Comment 26 Julien "_FrnchFrgg_" RIVAUD 2008-05-19 15:10:16 PDT
Regarding, there probably should be a short sentence explaining that the change from Firefox 2 to 3 regarding mouse buttons is for the better: we weren't following the X11 customs of mapping 6 7 to horizontal scroll, now we do, as every other GTK app, and probably Qt and Xlib ones too.

Chris, what do you think ?
Comment 27 Chris Ilias [:cilias] 2008-05-19 18:18:25 PDT
Sounds good to me. Do you want to make the edit? Email me, if you need help with the knowledge base. (or ask in
Comment 28 Brian 2008-06-18 01:45:53 PDT
Sorry to 'but in' with this, but this change affected me as a newbie to Ubuntu Linux when upgrading to FF3a4 within their packaging system.

I fully support the recent change to better comply with the Xorg standard, as opposed to keeping FF different than the standard.

I had to modify the original xorg.conf file in order to get the back/forward buttons to work as desired with FF2 - while not knowing what I was doing - according to the folks on Ubuntuforums.  With FF3a4, I found this thread and changed the 'about:config' to get it working again until I get enough info on changing the xorg.conf file to it's, apparently, standards-based state.

I have not been able to find a decent document explaining the button mapping options within Xorg - in Linux-newbie terms.  So it would be great if someone could add such documentation or a link at the previously mentioned URL:
(I wouldn't mind if someone wanted to post/email the link, as well. :-) 

Sorry if this is inappropriate for this forum.
Comment 29 Michael Monreal [:monreal] 2008-06-18 02:16:33 PDT
FWIW I installed Ubuntu Hary on my new laptop yesterday and this worked out of the box. The xorg.conf Ubuntu produced was VERY minimal mit it still worked as I would expect it to work (both touchpad with scroll area and wheel on the mouse work just fine).
Comment 30 Brian 2008-06-18 02:59:36 PDT
Hey Michael,

I've been wanting to upgrade my laptop to Hary(from Gutsy) for a while now, but don't know what problems to expect -- I'd like to talk about it more, but that is for another forum, unfortunately. :)

When you installed Hary - was it an upgrade or a fresh install?
I'm wondering whether an upgrade would rewrite the xorg.conf file, or what?

Comment 31 Michael Monreal [:monreal] 2008-06-18 03:11:54 PDT
It was a fresh installation. If you upgrade, you will most likely be asked if you want to keep your old xorg.conf (if you ever changed it). Make a backup and let Ubuntu write the new one. If for what ever reason Ubuntu does not try to update the file, run this: sudo dpkg-reconfigure -phigh xserver-xorg (after backing up the old config).

I have to say, I was rather surprised - but pleased - to have X working out of the box. Generally, if you do a Gutsy->Hardy update, make sure to backup everything as sometimes the update goes bad (especially if you tweaked a lot of things and installed 3rd party packages).

Note You need to log in before you can comment on or make changes to this bug.