Red Hat Bugzilla – Bug 244111
Button-4, considered button-6 by Xorg, does not perform Back page function in Firefox as in Windows Explorer and Windows Firefox
Last modified: 2018-04-11 15:18:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20070515 Firefox/188.8.131.52
Description of problem:
It is very handy to have the 4th button of my Logitech MouseMan Optical dual-sensor USB mouse perform a "Back-Page" function in Firefox. This functionality is available out-of-box and without any OEM drivers in Windows XP. Windows XP assigns the 4th and 5th button of any Intellimouse or ExplorerPS/2 type mice to the "Back-a-Page"/"Forward-a-Page" function by default for it's Windows/Internet Explorer interfaces and Mozilla follows suit with it's Firefox for Windows products. I have only been able to replicate this by manually inserting the following code in to my xorg.conf post-install:
Option "Protocol" "ExplorerPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Buttons" "6"
Option "ButtonMapping" "1 2 3 6 4 5
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora Linux
2. Open Mozilla Firefox
3. Attempt to navigate "Back-a-Page", after creating some browsing history for current session, using 4th mouse button to no avail
Firefox does _not_ navigate "Back-a-Page" when I click the 4th button of my mouse.
So many mice now offer more than three buttons, that, Fedora should anticipate this enhanced functionality by including this code in the stock xorg.conf _or_ this should be requested as default behavior upstream to Xorg.
Information on how Microsoft Windows treats this behavior:
Mouse Driver and SDK Aspects
The PS/2-compatible and USB mouse drivers and the User32 component in Windows supports the two extra buttons and the new, shorter Z/wheel data format reported by a 5-button wheel mouse. The first three bits of byte 1 in the input data packet are always mapped to the Left, Right, and Middle buttons, respectively, as specified earlier.
However, buttons 4 and 5 are not mapped to any specific User32 or Shell functionality; instead these buttons can be mapped by software applications to application-specific functionality. More specifically, these buttons are mapped to new WM_APPCOMMAND messages that are in Windows to notify software applications of application command events. For additional information about application development, see the Microsoft Platform SDK.
Some Microsoft applications provided with Windows will implement default mappings of buttons 4 and 5 to specific functionality. For example, the built-in Internet Explorer web browser will map buttons 4 and 5 to "Back" and "Forward" web page navigation, respectively.
Vendors who are producing or are planning to produce 5-button wheel mice that are not compatible with the activation method or the new input data packet format as specified earlier can still take advantage of the support provided by Windows and their built-in applications.
Windows 2000/Windows XP.
To take advantage of the support provided by Windows 2000/Windows XP, an IHV-specific filter driver is required. This filter driver should be inserted in between the port driver, I8042prt.sys, and the Mouse class driver, Mouclass.sys. This filter driver should implement the following functionality:
Initialize the mouse and set it to its 5-button wheel mode in a vendor-specific way.
This can be done by hooking the ISR routine in the filter driver. When the ISR hook is called, and when MouseState equals MouseResetting and ResetSubState equals Enable5Buttons, the filter driver should write any vendor-specific initialization commands to the mouse and return true each time so that the I8042prt.sys driver stops processing the data. The Pnpi8042 sample driver in the Windows DDK shows how I8042prt.sys driver handles an ISR hook.
Re-map the IHV-specific input data packet into the new format specified above before the data is passed on to the Mouclass.sys driver.
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
No information requested provided, no joy -- closing this bug as
INSUFFICIENT_DATA. Reporter, if you could, please, reopen with additional