GNOME Bugzilla – Bug 337852
side mouse button to go backwards
Last modified: 2012-12-11 18:44:18 UTC
the side mouse button should go 'back'. this is button 8 on my (fairly typical) mouse on ubuntu dapper with default config.
Related to bug 312073... Does this work in firefox? If so, what's the values of mousewheel.*.withnokey.action in about:config in ff?
This should certainly be in Epiphany by default, *not* as an extension.
This is definately the same as bug 312073, side mouse buttons are treated as 6 and 7 in X, as is a horizantal scroll wheel. The situation sucks, so we need to choose either horizantal scrolling or back/forward. The horizantal scrolling was choosen to be in-sync with what gtk+ does over scrollbars.
I assure you that the situation here is better. My side button is #8 (xorg in Ubuntu has been tweaked to deal with 4/5 6/7 being taken up for scrolling). I can only imagine that the other distros will follow the Ubuntu behaviour.
I have a Microsoft InteliMouse Explorer 3.0 USB mouse with Option "ZAxisMapping" "6 7" in xorg.conf, So my navigation(side) buttons worked as forward/back in Firefox. To get them working in epiphany, I only had to set the following to values in about:config to mousewheel.horizscrool.withnokey.action 2 mousewheel.horizscrool.withnokey.sysnumlines false I don't know how this will work with other mice, but if it's the same values, I would suggest to change the defaults in epiphany to the same as the ones in Firefox, so anyone switching to epiphany from firefox (or any other browser with working navigation buttons) feels right at home.
mousewheel.horizscrool.withnokey.action 2 mousewheel.horizscrool.withnokey.sysnumlines false Makes my back buttons work like in firefox and galeon. Using a Razer DiamondBack mouse (a gaming mouse). Xmodmap swaps side buttons 8 9 to report as 6 7 for back and forward (horizscroll) and buttons 2 3 to be swaped as of xorg7. I agree w/ default. However I expected horizontal scrolling to work in same fashion as other browser so this was very confusing to me coming from galeon. Changing it would have made my conversion much more smooth and default operations would be much more as expected (even if it is against gtk).
Mentioned in https://launchpad.net/distros/ubuntu/+source/epiphany-extensions/+bug/55077 as well.
*** Bug 351697 has been marked as a duplicate of this bug. ***
This is an Epiphany bug, not Epiphany-extensions.
*** Bug 469648 has been marked as a duplicate of this bug. ***
neither Nautilus (non spatial view) nor Epiphany allow my MS Intellimouse Explorer to go back and next with my 4th and 5th buttons Whereas it works in Firefox after having change my xorg.conf in Ubuntu to Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "ExplorerPS/2" Option "Emulate3Buttons" "false" Option "Buttons" "7" Option "ZAxisMapping" "4 5" Option "ButtonMapping" "1 2 3 6 7" Option "Resolution" "100" EndSection
We probably need to implement an event listener for app commands, the "AppCommand" DOM event. See https://bugzilla.mozilla.org/show_bug.cgi?id=360731 . Code goes in embed/mozilla/EphyBrowser.cpp along the other event listeners.
Also needs those command events to be dispatches; that's https://bugzilla.mozilla.org/show_bug.cgi?id=355477 .
*** Bug 587841 has been marked as a duplicate of this bug. ***
I wonder what the status is on this functionality with the new webkit backend?
I would like to mention that HID and other kernel's hid using devices are treated like keyboards, like most Microsoft mouses using the hid extensions to send things like standard multimedia keyboard codes
Created attachment 161256 [details] [review] mouse button 8 and 9 support
Sadly, I've found this bug a bit too late... I believe my patch is quite too much hard-coded (by the way, about:config is not showing anything for me), but still, any comments would be appreciated, since I'm trying to learn contributing-stuff and familiarize with GTK.
You are not too late at all. The bug has new relevance since Epiphany changed to the webkit backend. However, I am not the right person to review it. I wonder how it changes behavior when you press buttons while the mouse is hovering a link etc.
Thank you Johannes for the tip - yes, it behaves rather strange. I'll try to re-patch and simplify it a bit.
Created attachment 161373 [details] [review] mouse button 8 and 9 support, version #2 Mouse button 8 and 9 handling inside Web View. Links are ignored as in Firefox.
Comment on attachment 161373 [details] [review] mouse button 8 and 9 support, version #2 Since we are already handling presses by button in ephy-window.c, let's do this there. Also, a small comment: + webkit_web_view_go_back (&EPHY_WEB_VIEW (widget)->parent); You are never supposed to do this. The widget is already an EphyWebView, a WebKitWebView, a GtkWidget... all of them, since this is OO programming. Just doing WEBKIT_WEB_VIEW (widget) works fine and it's how you are supposed to go about this.
changing the (&EPHY_WEB_VIEW (widget)->parent) to (WEBKIT_WEB_VIEW (widget)) works fine. tried hooking it up in ephy-window.c, but ephy_window_dom_mouse_click_cb seems to only get called when the mouse is hovered over a link and button 8 or 9 is pressed.??? not sure best way to figure out where the signal is getting swallowed (if that is indeed what's happening)?
(In reply to comment #23) > changing the (&EPHY_WEB_VIEW (widget)->parent) to (WEBKIT_WEB_VIEW (widget)) > works fine. tried hooking it up in ephy-window.c, but > ephy_window_dom_mouse_click_cb seems to only get called when the mouse is > hovered over a link and button 8 or 9 is pressed.??? not sure best way to > figure out where the signal is getting swallowed (if that is indeed what's > happening)? You mean the callback is never called when buttons 8 or 9 are pressed?
(In reply to comment #24) > > You mean the callback is never called when buttons 8 or 9 are pressed? The callback is not called when buttons 8 or 9 on pressed, UNLESS the mouse is over a link during that button press (or possibly other DOM objects, too? haven't fully tested)
Xan Lopez: thank you for your comments. Yeah, I've messed up a bit - I'm new to this (gobject OOP, GTK+ pure C) stuff. Joe Barnett: Maybe that's why I moved out of ephy-window.c, or maybe I simply missed that callback - not sure. That was some time ago.
*** Bug 632077 has been marked as a duplicate of this bug. ***
Created attachment 172290 [details] [review] WEBKIT_WEB_VIEW version
*** Bug 620734 has been marked as a duplicate of this bug. ***
Xan, has this been committed already? Side mouse buttons work on FF and Chromium. (I haven't been able to test the 2.31 releases yet.)
I've been testing this patch on Epiphany 3.1.91.1 today and it works great! It works anywhere on the page etc.
Closing as FIXED as per the last two comments.
No don't close it, the patch isn't integrated! I applied it locally and tested it!
I completely misread this, sorry. :-( Reopening.
When will the patch go in? It doesn't seem to be in 3.4.0.1.
Not in 3.6.0 either... Epiphany is unusable for me without this.
Epiphany 3.6.1 and this bug still exists? Please guys, its 5 lines of code, a patch has already been included in this bugtracker. Just merge it in. It takes 5mins of your time and it will help many people who want to use epiphany as their default browser.
Created attachment 231297 [details] [review] e-web-view: enable back/forward mouse buttons Based on nautilus' (nautilus-window.c) button numbers and the bugzilla reports by users. Thank you Vincas Dargis and Joe Barnett for the previous patches.
Review of attachment 231297 [details] [review]: OK.
Thank you! Sorry for the delay everyone. Attachment 231297 [details] pushed as 8c53252 - e-web-view: enable back/forward mouse buttons