Status

()

The Mozilla Toolkit is a set of APIs, built on top of Gecko, which provide advanced services to XUL applications. These services include Profile Management, Chrome Registration, Browsing History, Extension and Theme Management, Application Update Service, and Safe Mode. (More info)

I just accidentally closed Firefox 57 when I meant to close just a single tab. It's a shame, because I really liked my experience with Firefox 57 so far; the Achilles' Heel of Firefox 57 is the Ctrl+Q keyboard shortcut, which closes the entire Firefox application, sits next to the Ctrl+W keyboard shortcut, which closes just a single tab. This is very frustrating and jarring for user experience. What's the priority for this particular bug? When can users expect functionality to modify or disable keyboard shortcuts?

I use FireFox with Google Docs, and I want Google Docs to be able to receive complex keyboard commands like Ctrl+Alt+Something, to do various tasks, such as to assign a paragraph style.
I use Firefox with LogMeIn, and when I am in a logmein remote control session, I want to use keyboard shortcuts like Ctrl-N and Ctrl-Q and I want those to go to the remote session I am typing on. I want to be able to see and DISABLE all global keyboard shortcuts.
I use FIrefox with (continue ad infinitum).
Firefox is a browser. It's a multi-purpose tool. Every single keyboard shortcut that exists that I can't disable or remap hurts me.
Quantum moved the ball back to about 2008 for me. This browser is for surfing CNN and Reddit and not useable for me as a daily driver until I have total control over its keyboard shortcuts.
This should not be an extension. This should be something in about:config, or about:config.keyboard or something.

Pretty much ditto to above. Right at this moment I'm using ghost and nvim-ghost to edit this bugzilla report from vim.
I work in datascience and web development. Chrome is ok, but I'm a big fan of FOI and FOSS and not having a hotkey for being able to quickly activate and externally edit from firefox is a massive cumulative drain on my day. Every time I reach for the mouse, I'm thrown off my beat.
Just one more voice asking that you please make this very important feature a serious priority.

(In reply to skyleach from comment #16)
> I work in datascience and web development. Chrome is ok, but I'm a big fan
> of FOI and FOSS and not having a hotkey for being able to quickly activate
> and externally edit from firefox is a massive cumulative drain on my day.
> Every time I reach for the mouse, I'm thrown off my beat.
I don't want to pull things off topic but, to be fair to Firefox, that's a bit tangential to this issue as it *is* already possible to have such a hotkey.
While it doesn't integrate deeply enough with the editor to support synchronizing unsaved changes, withExEditor does it (Ctrl+Shift+u by default and customizable).

My understanding for what is wanted for shortcuts (and is discussed here and in linked bugs) is this:
* Change a shortcut for a command programmatically/with extension UI (bug 1421811).
* Change a shortcut for a command through Firefox UI (this bug).
* Change any shortcut in Firefox through Firefox UI (no bug/many bugs).
* There are lots of bugs to add/remove shortcuts but not many seem to propose a UI for it. bug 588710 seems like the closest bug for this.
* bug 1422153 is duped here and suggests this but also other stuff, that maybe shouldn't have been duped.
* Support any shortcut I want—like escape, j or ]–in extensions (bug 1215061).
* Overwrite a Firefox shortcut with an extension shortcut (bug 1325692).
All of these bugs are referenced here and this bug should have a fairly specific scope. Comment 0 is something we are planning but the timeline/UX is not clear to me right now. Everything else should be discussed in their corresponding bugs.

Here's how I understand it:
The ask is for a UI that allows the user to see and modify all of Firefox's native keyboard shortcuts.
The user needs to be able to add a new shortcut to a command, and to modify or remove the existing shortcut.
In Firefox 56-, this functionality was provided by the KeyBinder extension.
https://addons.mozilla.org/en-US/firefox/addon/keybinder/
I would expect the Firefox native UI to be very similar to the one provided by that extension (screenshots are on the extension page), including having having the commands sorted into sections, and having the ability to search.
Keybinder also showed some keyboard shortcuts created by extensions and allowed those to be re-bound - for example, the key to open the Feeds Sidebar in the extension of the same name. I don't believe WebExtensions currently support those kind of global hotkeys anyway.

And here's how I understand it:
The request is for a UI to display to the user and allow them to modify the keyboard shortcuts a web extension has specified using the command section of the manifest file.
Currently, a user has no standard way to discover or modify an extension's shortcuts, basically making the commands thing useless, and requiring extension authors to ignore it and implement shortcuts manually in a way they can allow the user to customise the shortcut.
As mentioned in comment 19, that appears to be what this bug is about. If you want to change all of Firefox's shortcuts, that should really be tracked in a separate bug. Maybe both issues will be solved with the same solution, but they are still separate issues.
For me, regardless of whether a global shortcut preference is added, I would like to see an extension's shortcuts appear at the top of the extension's settings page (and without the extension author needing to add anything).

Okay, we definitely need to split this out into two bugs.
"Command shortcuts" is ambiguous; I always assumed it meant keyboard shortcuts for internal Firefox commands, but it could just as easily mean keyboard shortcuts for commands in WebExtensions.
Like you said, I'd imagine both issues would be solved through the same UI, but should be separate bugs.
Which one should be tracked by this bug, and which should be raised as a new one?
Either way, the description of this bug needs to be reworded.

(In reply to Nameless Voice from comment #22)
> Which one should be tracked by this bug, and which should be raised as a new
> one?
> Either way, the description of this bug needs to be reworded.
The scope of this bug is clearly stated by the component it is filed in, which is a WebExtensions component. For the generic UI, see the bugs that were linked in comment#19

(In reply to Stephan Sokolow from comment #17)
> (In reply to skyleach from comment #16)
> > I work in datascience and web development. Chrome is ok, but I'm a big fan
> > of FOI and FOSS and not having a hotkey for being able to quickly activate
> > and externally edit from firefox is a massive cumulative drain on my day.
> > Every time I reach for the mouse, I'm thrown off my beat.
>
> I don't want to pull things off topic but, to be fair to Firefox, that's a
> bit tangential to this issue as it *is* already possible to have such a
> hotkey.
>
> While it doesn't integrate deeply enough with the editor to support
> synchronizing unsaved changes, withExEditor does it (Ctrl+Shift+u by default
> and customizable).
Sorry, I believe I was a bit unclear. While I am talking about externally editing, it is insufficient for my needs to have a server spawning an editor as this process loop is too slow, and doesn't include numerous other extensions. Technically, I can copy and paste, edit, save, and paste back to the browser as well. Having the ability to activate other extensions on text area that maintain an active communication with the text area, and which communicate those changes to the editor in real-time, would be a more accurate description of my needs.
After looking at how to bind extensions to hotkeys, I found my way here.

This bug is linked in ublock origin's tracker about missing / broken keyboard shortcuts, which broke in Firefox 56. It's odd that currently it is not possible for extensions to make use of keyboard shortcuts for their functionality.
https://github.com/gorhill/uBlock/issues/2870#issuecomment-322234217 + 3 duplicate tickets. Hope this get's addressed by Firefox. This bug has currently 58 votes and has been open for 2 years.

(In reply to steve-_- from comment #25)
> This bug is linked in ublock origin's tracker about missing / broken
> keyboard shortcuts, which broke in Firefox 56. It's odd that currently it is
> not possible for extensions to make use of keyboard shortcuts for their
> functionality.
> https://github.com/gorhill/uBlock/issues/2870#issuecomment-322234217 + 3
> duplicate tickets. Hope this get's addressed by Firefox. This bug has
> currently 58 votes and has been open for 2 years.
It fits with the webextension spirit. Addons now also can't specify where they put context menu items nor can the user manually edit their position.

(In reply to Martin Giger [:freaktechnik] from comment #23)
> The scope of this bug is clearly stated by the component it is filed in,
> which is a WebExtensions component. For the generic UI, see the bugs that
> were linked in comment#19
In that case, we should use bug 588710 for the generic UI for Firefox-native controls.
Can someone rename this bug to make it clearer that it is about WebExtensions and not native Firefox functionality?

(In reply to skyleach from comment #24)
> Sorry, I believe I was a bit unclear. While I am talking about externally
> editing, it is insufficient for my needs to have a server spawning an editor
> as this process loop is too slow, and doesn't include numerous other
> extensions. Technically, I can copy and paste, edit, save, and paste back
> to the browser as well. Having the ability to activate other extensions on
> text area that maintain an active communication with the text area, and
> which communicate those changes to the editor in real-time, would be a more
> accurate description of my needs.
>
> After looking at how to bind extensions to hotkeys, I found my way here.
I understood your message to mean that you had gotten ghost and nvim-ghost working with Firefox, but it didn't have a hotkey to open/focus the editor. Specifically, that you were referring to this bug --> https://github.com/GhostText/GhostText/issues/113
I pointed to withExEditor because it demonstrates a workaround that allows some form of customizable keybindings right now which you might want to poke @bfred-it about.

I think the name was clear since this is filed in WebExtensions, but if it will keep things on topic I hope this helps.
Extensions can currently display their command shortcuts using the `browser.commands.getAll()` API to list them to users. If you think commands should be surfaced to users in other specific cases then feel free to file a bug about that. Currently sidebar shortcuts are displayed in the switcher. Browser action shortcuts could probably be displayed in a tooltip but I don't think that is the case right now.
The scope of this bug is well defined in comment 0, I don't think this bug needs more discussion right now. If you don't think this is going to solve your problem them adding to this bug is unlikely to provide a solution. You may want to look at the bugs linked in comment 19.

In my opinion this is a very important feature and I cant understand why Mozilla ignore it. I also think the guys from Mozilla do a great job but their strategy/tactic to reach more people is not good. The biggest part of user come from "OS installs from a friend/vendor". So it should be the main target to improve and support the usability for power users. The power user will install Firefox on the computer of "normal dying people". Shortcuts, Tab Grouping, Web Development, Performance, Privacy, Security should be the main targets. "Why should I use Firefox if the IT-Professional tell me Chrome is "faster" and better?"
This problem could be ?easily? solved with an extra menu under settings "Shortcuts" and offer a fully customizeable shortcut menu. We only need a Shortcut API and an integrated Firefox Shortcut API to customize.
Example:
[Del. Shortcut] [KEY] [Source] [Description]
[X] [STRG+T] [Firefox Core] [Open a new Tab]
[X] [STRG+ALT+F1] [Tree Style Tab] [Open TST Sidebar]
[X] [STRG+ALT+F1] [Tree Style Tab] [Open TST Configuration]
[X] [STRG+SHIFT+ALT+X] [Feedbro] [Open Feedreader]
[X] [ ] [ ] [ ]
[[Add new Shortcut]] [[Restore standard Shortcuts]] [[Delete All Shortcuts]] (Buttons - self explanatory)
[ ] Allow new installed Addons to change this configuration.
[ ] Allow Addons to change Firefox Core shortcuts. (Checkboxes - self explanatory...)
Key: Self defined up to 4 keys. (Click in and push combination)
Source: Name of the source which provide the shortcut [Dropdown menu of available Sources (FF Core, FF Dev Bar, Addons as ex.]
Function: Offer the provided Shortcuts by the chosen source [Dropdown menu - depending on Source]
Firefox Core need to offer the basic Shortcuts. The Addons only need to provide a "Description" of each provided shortcut and an internal function which is linked to the selected keystroke. Source = Addon Name
A warning after Addon installation would be fine.
Simple - Efficient - Future proof and all the shortcut issues are gone.

A hardcore enhancement would be an option to add something like "Open Website" and insert Adress under "Description".
"Shift-X" to open a self defined "daily visited" website as example? (Google, Webmail, News, Mobility Connections...) I'm sure there will be some more ideas and the fight for shortcuts will end.
Sorry for double comment.

A GUI would be great, but will take long. Alterative is to implement prefs, or Webextension API that can change these prefs for all shortcuts FF is currently using. E.g. "browser.shortcuts.closeWindow;Alt+F4" and extensions like https://addons.mozilla.org/de/firefox/addon/shortkeys/?src=search would be able to change those.

I want to second the focus of Comment 20 and also several other comments about interference of shortkeys with other applications. The mentions here are far from complete. (The most irksome thing for me is trying to use Emacs in the Guacamole remote desktop gateway and having interference with ctrl+n, ctrl+t, and ctrl+w.)
It is surprising to me that complaints about this go back as far as 2 years on this bug and sometimes even further on related bugs, but there still has not been a resolution.
See also e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c69https://bugzilla.mozilla.org/show_bug.cgi?id=1320332#c12
The issue is in other bug threads as well, and is something for which other people are searching for solutions in other online fora.
I don't think this should be left for random extension writers but rather should be a high priority fix.
(Sorry I am a newbie to Bugzilla so I'm not sure how things actually do ultimately get fixed; this is the one place where I was able to find that the bug is marked as assigned to somebody and given a priority. I don't know exactly what the priorities mean; P2 sounds pretty good, but I do hope somebody can resolve this soon.)

These patches are WIP, when attempting to overwrite an existing command (like ctrl+w) the existing command is executed (in this case the tab is closed). This isn't ideal, and I'm not sure if we want to support overwriting commands right now (although it would seem reasonable).
Regardless, I'd say having the tab close if you try to set something to ctrl+w is a blocker for now.

"I'm not sure if we want to support overwriting commands right now"?
Firefox is the only browser (maybe except Explorer) that doesn't allow users to redfine shortcut keys.
It's the main reason I switch to other browser until this will be fixed.
I don't want any workarounds, just built-in possibility to redefine keyboards. I don't want to learn your shortcuts, I want to personalize browser what I want, not adapting to someone's choice. "Flexible" - it's a word that you should learn. Firefox makers forgot about that.

I tried out your patches and posted some review comments.
Your isSystem validator is stricter than what is allowed in the manifest file.
By default, I am able to override Cmd-Q on macOS (https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/ ). The UI complains about the use of this shortcut, but when blurring, it still reverts to the previous Cmd-Q shortcut.
I hope that you fix this by allowing built-in shortcuts such as Cmd-Q/Ctrl-Q rather than blocking all "system" shortcuts.
(In reply to Mark Striemer [:mstriemer] from comment #39)
> Regardless, I'd say having the tab close if you try to set something to
> ctrl+w is a blocker for now.
On macOS, the default action of Cmd-W is successfully prevented already.
On Linux, I can prevent the default action using a system listener in the main process:
// document is the browser.xul document
Services.els.addSystemEventListener(document, "keydown", e => {e.preventDefault();}, true);
I tried to register a listener in the content process, but that did not work, possibly because of the "reserved" attribute on the key.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEventListenerService#addSystemEventListener()
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/reserved
It is probably a good idea to ask others whether this is a good approach before committing to it though. There might be a footgun that I'm unaware of.

I think I've run out of time for 65 on this one. The patch has been brought up to date with inbound but with reviews needed and soft freeze around the corner probably best to wait for an early 66 landing.

Linkable site:
Also I agree with some commenters that it would be great if I could link from my WebExtension to this page, so I can have a button "Customize hotkeys" that takes the user to that site, so they can adjust the hotkey there.

Another feature requests:
IMHO you should list add-ons without any hot keys/commands defined at the bottom of the list. If I, as a user, want to customize the hot keys of an add-on, I do not want to search for it, respectively scroll over 20 add-ons where I cannot even set a hot key, but find it directly, so I am faster and not so much annoyed.

Note:
Also note that some add-ons also show a huge amount of defined hot keys there (https://flagfox.net/viewtopic.php?f=3&t=726), so this may be a little confusing, but I also see no way to dynamically add/request new commands in the WebExtension API, as you always have to pre-define them in your manifest.json.

If I try to enter "Ctrl+F4" there (on Linux; German QWERTZ keyboard) it closes the tab of about:addons.
Not for me, latest Nightly, installed addon Shortkeys and entering "Alt+F4" for close tab leads to the expected behavior (tab is closed and FF window closure is prevented). Need to inform Peter about that.

Not for me, latest Nightly, installed addon Shortkeys and entering "Alt+F4" for close tab leads to the expected behavior (tab is closed and FF window closure is prevented). Need to inform Peter about that.

Ctrl+F4 is something different than Alt+F4 though. Different places where they are handled. My guess would be that this shouldn't be working (i.e. Alt+F4 shouldn't be assignable). I can't assign Alt+F4 (browser closes and shortcut is never saved), so I assume my OS is inserting a stronger handler than yours.

Ctrl+F4 is something different than Alt+F4 though. Different places where they are handled. My guess would be that this shouldn't be working (i.e. Alt+F4 shouldn't be assignable). I can't assign Alt+F4 (browser closes and shortcut is never saved), so I assume my OS is inserting a stronger handler than yours.

Case in point: Under X11, Alt+F4 is handled by the window manager and the applicaton never receives KeyPress/KeyRelease events for it.

It can usually be rebound in the window manager's hotkey settings. (eg. ~/.config/openbox/... or the "KWin" section of KDE's Global Keyboard Shortcuts control panel... which, in all honesty, I'd been hoping this bug would take design inspiration from in providing a unified, searchable configuration UI for all registered hotkeys, both built-in and extension-defined.)

Note:
Also note that some add-ons also show a huge amount of defined hot keys there (https://flagfox.net/viewtopic.php?f=3&t=726), so this may be a little confusing, but I also see no way to dynamically add/request new commands in the WebExtension API, as you always have to pre-define them in your manifest.json.

Filed bug 1521389 for this. Please fix this before this new GUI hits release.