User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20061004 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20061004 Firefox/220.127.116.11 I'm attaching a simple patch that maps X mouse buttons 8-9 to the back/forward commands. The consensus amongst GTK+ and Qt seems to be that buttons 6-7 are for horizontal scrolling. Many new mouses have both 4 way scroll buttons and history control buttons, so we have to map them to different numbers. I'm using the appCommand infrastructure as used on windows. Reproducible: Always
Created attachment 241282 [details] [diff] [review] patch against 18.104.22.168 to map buttons 8-9 to back/forward
I know the patch is against 1.5, but the code doesnt seem to be to different in 2.0 or HEAD
Thanks for the patch! But I don't think this kind of patch would be accepted for branch, since it's not a crash fix or security fix (or major problem). Does this also need fixing on trunk? Could you make a patch for trunk? Thanks.
Please do. This is a feature I've been missing from day one. Setting up imwheel on every machine is a bit of a pain.
Definitely a worthwhile patch, esp. for Mighty Mouse etc., from an unexpected email address :). CONFIRMing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Patch submitter (no name given), Thanks a lot for the patch! Can you please update to latest trunk? The patch no longer applies. Once you did so, please request review from appropriate person using "Edit" on your patch. ccing reed for help (I can't see an obvious candidate for review). I assume the user can still assign system-wide functions to these mouse buttons (e.g. switch window), and this feature won't interfere? Ideally, it would be configurable within Mozilla. I'd prefer to map them to e.g. "switch to next tab on the right" and "close tab" instead of Back/Forward.
Assignee: nobody → tester
Component: OS Integration → Widget: Gtk
Product: Firefox → Core
QA Contact: os.integration → gtk
Created attachment 302501 [details] [diff] [review] Patch ported to trunk Here is a patch ported to the trunk. It shouldn't interfere with anything system-wide as I'd expect that to eat the event before we receive it. As for making it configurable, that would be nice, but I see this happening at a higher level (so that it would be available for windows/mac/etc..). I'm asking roc for review since he's reviewed most of the recent patches to this file.
Also, I took some of the code used to other buttons event and put it in a more generic method, if its not required, we could just use the DispatchCommandKeyEvent() () method (and maybe renamed it to DispatchCommandEvent()..)
Yeah, let's just use DispatchCommandKeyEvent. Rename it if you want.
The position doesn't matter? I'll attached an updated patch
I don't think it does.
Created attachment 303461 [details] [diff] [review] Simplified patch against trunk Here's a simplified patch as requested.. Btw, the reason for adding the position onto the event was that the windows version does it.
Comment on attachment 303461 [details] [diff] [review] Simplified patch against trunk When you ask for review, you should always specify a requestee. Otherwise people might not notice your request.
Attachment #303461 - Flags: review? → review+
Status: NEW → ASSIGNED
Version: unspecified → Trunk
Attachment #303461 - Flags: superreview?(roc) → superreview+
Summary: [patch] map mouse buttons 8-9 to back/forward → map mouse buttons 8-9 to back/forward
Checking in widget/src/gtk2/nsWindow.cpp; /cvsroot/mozilla/widget/src/gtk2/nsWindow.cpp,v <-- nsWindow.cpp new revision: 1.260; previous revision: 1.259 done Checking in widget/src/gtk2/nsWindow.h; /cvsroot/mozilla/widget/src/gtk2/nsWindow.h,v <-- nsWindow.h new revision: 1.85; previous revision: 1.84 done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9beta4
You need to log in before you can comment on or make changes to this bug.