GNOME Bugzilla – Bug 762631
Add Ctrl+Tab and Ctrl+Shift+Tab to switch between tabs
Last modified: 2017-05-18 17:11:02 UTC
Despite the number of demands for this closed as "RESOLVED NOTABUG", "RESOLVED INVALID" or "RESOLVED WONTFIX", there clearly is a demand for this feature. Here are the reasons why I think we should have these shortcuts: - A significant number of users demand it - Most if not all major Web browser which potential users probably are used to propose Ctrl+Tab - PageUp/Down are more and more rare on new keyboards while Ctrl, Shift and Tab or equivalent keys are always present - Ctrl, Shift and Tab rarely move from one keyboard to the other while PageUp/Down could be found on many different positions, hence the first one helps to keep muscular memory when switching keyboards - The semantic of up and down is not clear enough: which one means next and which one means previous: on most keyboards these keys are one ontop the other - The semantic of Tab and Shift+Tab is more understandable: the simple one is for next and adding Shift revert the operation - PageUp/Down takes the hand used by most users to control the pointer while using Tab makes them able to switch through tabs while moving the pointer which is a huge speed boost - These shortcuts don't conflict with any other - We don't have to remove the existing ones - It worth what it worth, but I didn't use Epiphany for years mostly because of that and it's probable other persons did the same
Created attachment 322354 [details] [review] ephy-window: Add Ctrl[+Shift]+Tab shortcuts I couldn't test this properly as no keyboard shortcuts using Shift currently work on my JHBuild install, I think it should work though.
(In reply to Adrien Plazas from comment #1) > Created attachment 322354 [details] [review] [review] > ephy-window: Add Ctrl[+Shift]+Tab shortcuts > > I couldn't test this properly as no keyboard shortcuts using Shift currently > work on my JHBuild install, I think it should work though. Er yeah, that's *really* weird, I have the same problem. I doubt this has anything to do with jhbuild, it's probably a real regression. A few things I would check: * Build GTK+ 3.18 in your jhbuild environment (cd into the gtk+ directory, 'git checkout 3.18.0', 'jhbuild buildone -n gtk+'), does that fix it? If so, let's bisect GTK+. * Check if shortcuts using Shift are broken in other apps. * Revert Epiphany commit ebbc2351b76fd1644685a800ef0ffb635f92deb2, does that fix it? I think it will not, because that's in the 3.18 branch and we don't have this problem there.
Review of attachment 322354 [details] [review]: Adrien discovered this is a regression in GTK+. Please post a link here to the GTK+ bug that you'll file.
https://bugzilla.gnome.org/show_bug.cgi?id=762720 I forgot about it, thanks.
Review of attachment 322354 [details] [review]: ::: src/ephy-window.c @@ +292,3 @@ + { GDK_KEY_Tab, GDK_CONTROL_MASK, "TabsNext", FALSE }, + { GDK_KEY_Tab, GDK_CONTROL_MASK | + GDK_SHIFT_MASK, "TabsPrevious", FALSE }, Ctrl+Shift+Tab doesn't work here even with GTK+ revered: it switches the focus between focusable widgets instead of switching to the previous tab.
Created attachment 350602 [details] [review] ephy-window: Switch tabs with [Shift+]Ctrl+Tab Switches among tabs with Ctrl+Tab (next) and Shift+Ctrl+Tab (previous) instead of Ctrl+PgDown and Ctrl+PgUp.
Review of attachment 350602 [details] [review]: Thanks for your contribution. Ctrl+PageUp/PageDown are standard shortcuts for switching tabs in GNOME, so I don't want to remove them. I'd accept a patch that adds the new shortcuts without removing the existing ones, OK? ::: src/ephy-window.c @@ +542,3 @@ keyval != GDK_KEY_Page_Down && /* Next Tab */ + keyval != GDK_KEY_KP_3 && /* Next Tab */ + keyval != GDK_KEY_Tab; /* Next Tab */ Nit: for the comment, please match the indentation of the other shortcuts. All the other comments start on the same line. @@ +550,3 @@ keyval != GDK_KEY_Page_Down && /* Move Tab Right */ + keyval != GDK_KEY_KP_3 && /* Move Tab Right */ + keyval != GDK_KEY_Tab; /* Previous Tab */ Ditto.
Please double check that it doesn't break normal navigation between focusable elements with [Shift+]Tab too; not being able to fix that it the reason why I stopped there.
Hm, good point. Fortunately we have finer-grained control over that nowadays. George has already found the function that filters key press events from being received from the web view (which didn't exist when you were working on this) so it's now easy to ensure that Ctrl+Tab and Ctrl+Shift+Tab skip the web view, while normal Shift+Tab gets consumed by the web view. At least, I think it should work properly.
Created attachment 350649 [details] [review] Hi guys, thanks for the feedback! Michael, this patch adds back Ctrl+Pg_Down and Ctrl+Pg_Up and fixes the alignment of the comments - thanks for the tip. Adrien, I've tested in a bunch of websites and it seems to work (not being catched by the web view) although I just noted that switching to previous tab requires two Shift+Ctrl+Tab if you already clicked somewhere inside the web view. Is this related to focus on tabs widget? Any tips (that doesn't happen with Ctrl+Tab though)?
*** Bug 782621 has been marked as a duplicate of this bug. ***
Review of attachment 350649 [details] [review]: Sorry, looks like I missed this somehow! The patch *looks* good, and it's exactly what I would have done. But I found one problem when testing it. ::: src/ephy-window.c @@ +550,3 @@ keyval != GDK_KEY_Page_Down && /* Move Tab Right */ + keyval != GDK_KEY_KP_3 && /* Move Tab Right */ + keyval != GDK_KEY_Tab; /* Previous Tab */ Turns out this doesn't work. Ctrl+Shift+Tab still gets swallowed by the web view if the focus is within an HTML input element, even though this code should prevent that from happening. I guessed that maybe the key press is being converted into something other than GDK_KEY_Tab, and indeed it is turning into GDK_KEY_ISO_Left_Tab... whatever that is. Seems that Shift+Tab gets normalized into GDK_KEY_ISO_Left_Tab, and then GDK_SHIFT_MASK has been used up. So you actually don't want to check this here, because it doesn't work, but instead check for GDK_KEY_ISO_Left_Tab up above in the GDK_CONTROL_MASK condition. And add a descriptive comment, because that is really confusing. Something like this: keyval != GDK_KEY_KP_3 && /* Next Tab */ keyval != GDK_KEY_Tab && /* Next Tab */ keyval != GDK_KEY_ISO_Left_Tab /* Previous Tab (Shift + Tab -> ISO Left Tab) */
I'm going to go ahead and push my modified version under your name... hope you're OK with that.
Thanks for the feedback Michael, and sorry for not replying before. Please go ahead with your modified version. Cheers.