1389644 - GNOME is hardcoded to use "alt" for switching tabs instead of accel+1...9

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, enhancement)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

At the moment Firefox enforces "alt" to be the modifier key for selecting tabs.

Every other piece of UI follows "accel" which can be configured, but since bug 429219, this value is hardcoded for Gnome.

See: http://searchfox.org/mozilla-central/rev/4b79f3b23aebb4080ea85e94351fd4046116a957/browser/base/content/browser-sets.inc#370

This breaks certain workflows and with the Keybinder extension (which allowed me to customize it) gone, I'd like to fix it.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: Bug 1389644 - Dehardcode selecting tab (accel+1...9) modifier key for Gnome.

Review commit: https://reviewboard.mozilla.org/r/167706/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/167706/

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

Non-blocking NI on :masauyki, since he's been the author of the early patch (10 years ago) so maybe he'll remember why he singled out Gnome and be able to confirm that we're ok to change that :)

Comment 3

[Dão Gottwald [:dao]]

Comment on attachment 8896458 [details]
Bug 1389644 - Dehardcode selecting tab (accel+1...9) modifier key for Gnome.

https://reviewboard.mozilla.org/r/167706/#review172928

Accel means Ctrl here, not Alt. So that's not what we want by default for Gnome.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

> Accel means Ctrl here, not Alt. So that's not what we want by default for Gnome.

What is the right modifier key then? 

chromeAccess is Alt on Windows and Unix, and Ctrl for Mac.
accel is Ctrl on Windows and Unix, and Cmd for Mac.

Would it then make sense to do

#ifdef XP_GNOME
#define NUM_SELECT_TAB_MODIFIER chromeAccess
#else
#define NUM_SELECT_TAB_MODIFIER accel
#endif

or can you recommend another way to solve it?

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

(p.s., it's a pseudo code, I realize that "chromeAccess" is not a proper modifier :) I just don't know how to get it into the .inc)

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The reason was, Ctrl+[0-9] on Linux may cause inputting characters like French keyboard (according to the comments of bug 429219). So, you need to test it with French keyboard or something before landing the patch.

# I wonder, changing existing such major shortcut key of Firefox may cause making users confused. If you claim they won't be confused, is the shortcut really necessary?

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

> The reason was, Ctrl+[0-9] on Linux may cause inputting characters like French keyboard (according to the comments of bug 429219). So, you need to test it with French keyboard or something before landing the patch.

So, I was trying to read this bug and thought that the problem is specific to Windows (that's the UA of the reporter and OS of the bug), not Linux.

On Linux, alt is the correct default key for selecting tabs (that's the same key the default Gnome Web Browser is using, so I assume it follows their HiG).

The only thing I'd like to dehardcode it, and make it possible to follow the behavior on Mac (and Windows?) where the same modifier is used to open new tab (modifier+t), switch to the next tab (modifier+tab) and select a tab (modifier+1).

I got used to this setup when I was on Mac and when I switched to Gnome I kept the same model. Now with the Keybinder extension gone, I got to the point where I have to write a patch to enable customization of the behavior :)

If that requires some JS runtime logic to get the Preference and switch the modifier, I'm happy to write the code, I'd just like to understand what would be the right path to approach it :)

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #7)
> > The reason was, Ctrl+[0-9] on Linux may cause inputting characters like French keyboard (according to the comments
> > of bug 429219). So, you need to test it with French keyboard or something before landing the patch.
> 
> So, I was trying to read this bug and thought that the problem is specific
> to Windows (that's the UA of the reporter and OS of the bug), not Linux.

I'm not sure about Windows, though. As far as I know, some South-Asian keyboard layout on Windows uses Ctrl+Shift+[0-9] as inputting character.

> On Linux, alt is the correct default key for selecting tabs (that's the same
> key the default Gnome Web Browser is using, so I assume it follows their
> HiG).

Sounds good.

> The only thing I'd like to dehardcode it, and make it possible to follow the
> behavior on Mac (and Windows?) where the same modifier is used to open new
> tab (modifier+t), switch to the next tab (modifier+tab) and select a tab
> (modifier+1).

Hmm, on macOS, Alt key isn't available for shortcut keys because it works as AltGr on other platforms with *all* keyboard layouts. On the other hand, Ctrl key on macOS is also special. It's used as Emacs like shortcut key modifier. Even if Ctrl+[0-9] are not used on default macOS settings, they might be used by users who customize their OS level shortcut key. Now, we support OS level customized shortcut key on macOS since 55 or 56 (I don't remember the exact version). So, using Command key on macOS is reasonable...

> I got used to this setup when I was on Mac and when I switched to Gnome I
> kept the same model. Now with the Keybinder extension gone, I got to the
> point where I have to write a patch to enable customization of the behavior
> :)

Hmm, ideally, we should have a global keybinding customizer which can modify <key> elements in chrome. WebExtensions cannot customize key combinations in chrome anymore. So, after 57, such function should be implemented by Firefox (toolkit?) itself.

> If that requires some JS runtime logic to get the Preference and switch the
> modifier, I'm happy to write the code, I'd just like to understand what
> would be the right path to approach it :)

If you want only to make the modifier for switching tabs customizable, I guess that you need to implement the keyboard event handling with JS, but it will cause the "key hell" issue. So, perhaps, it's impossible from a point of view of internationalization.

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

> Hmm, ideally, we should have a global keybinding customizer which can modify <key> elements in chrome. WebExtensions cannot customize key combinations in chrome anymore. So, after 57, such function should be implemented by Firefox (toolkit?) itself.

:kmag, do you know is there's a plan to add ability to rebind UI keys via WebExtensions?

Comment 10

[Zibi Braniecki [:zbraniecki][:gandalf]]

Ok, there seem to be some API for that: bug 1325692, bug 1303384 and bug 1320332.

I'll play with writing an extension for that.

Comment 11

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: selectTab.zip

K'boom. I was able to create a web extension for the functionality I need. Sweet :)

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

Leaving it here in case anyone ever has the same problem and find it.

Comment 13

[[e-mail]]

I know a web extension fixes this issue but it really should be customizable in Firefox.

Comment 14

[Zibi Braniecki [:zbraniecki][:gandalf]]

I am not involved in work in this area.