Side mouse buttons no longer work as back and forward

RESOLVED INVALID

Status

()

Core
Widget: Gtk
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: Ash Heron, Unassigned)

Tracking

({relnote, user-doc-complete})

Trunk
x86
Linux
relnote, user-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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:  
Unresponsive

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"
EndSection
I've heard numerous complaints about this lately. What did we do that broke this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
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.
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

9 years ago
_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.
See bug 355477
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

9 years ago
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Reporter)

Comment 7

9 years ago
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."
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

9 years ago
Can you please post an example xorg.conf so that we may see how to get the side mouse buttons working with firefox?
Taken from http://gentoo-wiki.com/HOWTO_Advanced_Mouse#XOrg.conf_ButtonMapping :

> 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

9 years ago
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.
Can we close this bug as INVALID ?

Comment 13

9 years ago
I'd leave it open until this is definitely in the release notes.  Perhaps reassign?
beltzner, please relnote this.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Keywords: relnote
Resolution: --- → INVALID
(In reply to comment #14)
> beltzner, please relnote this.

I added this to http://wiki.mozilla.org/QA/Firefox3/TestResults/Beta4/Release_Notes#Proposed_relnote_items_for_beta_4 -- somebody that's been better following this bug may wish to re-write my wording there.

Updated

9 years ago
Keywords: user-doc-needed

Comment 16

9 years ago
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

9 years ago
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

Updated

9 years ago
Duplicate of this bug: 422365

Updated

9 years ago
Duplicate of this bug: 424722

Comment 20

9 years ago
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

9 years ago
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

9 years ago
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.
user-doc-complete
<http://support.mozilla.com/kb/Mouse+buttons+do+not+work+as+Back+and+Forward>
Keywords: user-doc-needed → user-doc-complete
Can the required about:config changes be made default for Linux installs?
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
Regarding http://support.mozilla.com/fr/kb/Mouse+buttons+do+not+work+as+Back+and+Forward, 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 ?
Sounds good to me. Do you want to make the edit? Email me, if you need help with the knowledge base. (or ask in mozilla.support.planning)

Comment 28

9 years ago
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:
http://support.mozilla.com/fr/kb/Mouse+buttons+do+not+work+as+Back+and+Forward
(I wouldn't mind if someone wanted to post/email the link, as well. :-) 

Sorry if this is inappropriate for this forum.
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

9 years ago
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?


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).
You need to log in before you can comment on or make changes to this bug.