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?
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...
_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
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.
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.
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".
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 ?
I'd leave it open until this is definitely in the release notes. Perhaps reassign?
beltzner, please relnote this.
(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.
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.
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
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
It is changeable in about:config. If you have back/forward mapped to 6/7 respectively, just use the settings in comment 17.
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.
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)
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).
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).