User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161115075801 Steps to reproduce: Quoting the "webextensions" page of Mozilla https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/commands: > If a key combination is already used by the browser (for example, > "Ctrl+Shift+R"), or by an existing add-on, then you can't override it. You will > be allowed to define it, but your event handler will not be called when the > user enters it. There are addons which going to be awfully broken because of this upon rewriting from XUL to WebExtensions. To name a few: pentadactyl, vimperator. E.g. Ctrl+p and Ctrl+n swtches tabs with them. And mandating for a user to manually disable every browser's key before enabling the addon, and afterwards — in case a user decided to disable addon for awhile — re-enabling them one-by-one back, is a horrifying experience. One possible solution to the problem, is to make a dialog, listing installed addons and the browser, and allowing to move up/down the order of preferred keybindings. There might be other solutions as well, but it have to be solved before removing XUL.
My usecase: in my UsableHomeButton extension , the Alt+Home keyboard shortcut (normally opens the browser’s start page) is overridden to perform the same action as pressing my modified version of the “Home” button of Firefox. Additionally, Shift+(Alt+Home) in the extension acts as pressing the “Home” button while holding the Shift key (opens in new browser window), and Ctrl+(Alt+Home) acts as pressing the “Home” button while holding the Ctrl key (opens in new tab).  https://addons.mozilla.org/firefox/addon/usablehomebutton/
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1287093
(In reply to Andy McKay [:andym] from comment #2) Andy, I believe those bugs are about different things. IIUC, the bug 1287093 is about adding a _user_ interface for configuring keyboard shortcuts, while the current bug is about adding a possibility to override keyboard shortcuts (without any participation of user) via WebExtensions API like that's _already_ possible via XUL/XPCOM. So the current bug is not about adding something new, bug about just providing a feature equivalent to one we already have.
Ok I see, thanks for the clarification.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Component: WebExtensions: General → WebExtensions: Frontend
Priority: -- → P5
This came up here as well: https://github.com/lusakasa/saka-key/issues/53
This is pretty important from UX point of view. There is currently no addon to add or edit shortcuts for FF 57, but it should be treated as top priority to have this functionality by default in FF.
Hi, Some OS or some keyboard layout collide with firefox 57 firefox-quantum keyboard shortcut. Users was disabling some conflicting keyboard shortcut, for daily usage. It is very important do allow user to modify or disable any keyboard shortcut. Question is on lot of websites: * How to remove keyboard shortcut in firefox57? -> https://support.mozilla.org/en-US/questions/1188157 * https://superuser.com/questions/1272551/disable-single-shortcut-in-firefox-quantum/1273827#1273827 * https://www.reddit.com/r/firefox/comments/77gm9u/changing_default_keyboard_shortcuts_in_firefox_57/ etc. Please add some documentation where to edit or disable shortcut. My killing shortcut is CTRL-SHIFT-C, poping Inspector, as I just want to Copy, but my terminal is copying with this shortcut. I'm always raging against firefox opening the Inspector. I was disabling this shortcut before, how do I do? Sylvain.
(In reply to Sylvain Viart from comment #8) > My killing shortcut is CTRL-SHIFT-C, poping Inspector, as I just want to > Copy, but my terminal is copying with this shortcut. I'm always raging > against firefox opening the Inspector. I was disabling this shortcut before, > how do I do? I didn't want to mention it since it was just one data point, but I actually have the same problem. While I'm doing development work or anything that involves heavy interaction with the terminal, I often find myself accidentally opening up the inspector) and then resenting the wasted time to switch to the mouse to dismiss it).
I signed up only to say that I'd really appreciate a shortcuts editor integrated into the vanilla Firefox quantum. My problems are with ctrl+q (I'd like to move it to my system -XFCE- default quit shortcut, which is ctrl+shift+q) and ctrl+p, because they are too close to ctrl+w (close tab) and ctrl+[ (go back one page), respectively. (In reply to Stephan Sokolow from comment #9) > While I'm doing development work or anything that involves heavy interaction > with the terminal, I often find myself accidentally opening up the > inspector) and then resenting the wasted time to switch to the mouse to > dismiss it). I also have this problem Stephan, and I'm able to close the dev panel using the keyboard, with either ctrl+i or F12.
(In reply to Alberto Chiusole from comment #10) > I also have this problem Stephan, and I'm able to close the dev panel using > the keyboard, with either ctrl+i or F12. I don't want this to go off-topic any further, so please don't reply to this, but neither of those applied for the following reasons: F12 keypresses never reach Firefox because they're the default global hotkey for "toggle terminal" in Yakuake and I chose to preserve my muscle memory when I switched to urxvt's kuake plugin as a more lightweight alternative. I don't know how you changed it on your system, but Ctrl+i is bound to the Page Info dialog on mine and, even if it weren't, there's no way I could have known that because Firefox hasn't rendered its menus with keyboard-shortcut hints in years (one of the original core motivations of menus as a UI element was to make keyboard shortcuts discoverable) and there's no keyboard remapping UI to serve double duty as a keybinding quick-reference sheet.
The lack of this API is quite bad for those of us used to traditional UNIX shortcuts, like Ctrl-W to delete the word before the cursor. Ctrl-W closes the current tab in Firefox 57, so I am continually closing the tab while filling in web forms. It would be great to have an API to disable Ctrl-W so this stopped happening.
Very oddly, sometimes Firefox's shortcut is overridden but sometimes isn't. For example, Ctrl-K (Focus to the search bar or the location bar on Windows and Linux) cannot be overridden, but Ctrl-Up/Down (Scroll to top/bottom on Windows and Linux) can be overridden. This difference is made from this code: https://searchfox.org/mozilla-central/rev/033d45ca70ff32acf04286244644d19308c359d5/browser/components/extensions/parent/ext-commands.js#249,252,254 Because shortcuts for non-printable keys (Up, Down, PageUp, PageDown, and others) are defined by "keydown" and Firefox's shortcuts are detected on "keypress", addon's shortcut for those keys always work before Firefox's one. I can't imagine why the 'event="keydown"' is not applied for regular keys (A-Z)...
Any updates on this? My use case is: "I want to disable Ctrl + Q, because I've never used it to close Firefox on purpose, only by accident."
Verbose and very loosely related remarks, skip at will:) # ctrl+shift+w anecdote (Similar to previous comment.) Back in the days of yore when Firefox bloomed with almost unlimited customizability I got used to have two distinct commands for closing tab: one native, that activates tab to the right and the other provided by glorious Keyconfig (custom action) that activated left tab. I've configured it to be invoked with ctrl+shift+w (as addition to native ctrl+w) effectively overriding its native "exit app" command. Even now my muscle memory sometimes kicks in and I accidentally nuke Firefox window this way. (Good thing it is nearly impossible to lose something this way nowadays and also neat that current startup time makes this kind of accident quite bearable. Thumbs up!) # Impact overview Extension authors (and even users in settings in question) should have better overview of what they are overriding. Anecdote: Till this day I've encountered two distinct WebExtensions that successfully remapped alt+down shortcut, effectively removing ability to open native <select> element with keyboard (what I happen to use regularly). I've seen browser console warnings for such scenarios, but as practice shows it is not bulletproof. # Unpredictable availability Speaking of successful overrides, current security policy allows WebExtensions to register "global" (browser-wide) keyboard commands that works even when active tab displays content from otherwise "restricted" origin (AMO, about..:, moz-extension:..) but other means of invoking the very same command are limited to non-restricted whitelist. This results in highly confusing outcome when I can for example happily close ANY tab with keyboard shortcut set by extension but I cannot do the same by mouse gesture provided by the very same extrion when active tab displays something from AMO. Technically it is logical and surely it has been discussed before, but i wanted to vent this out. # No central register of commands This was called for already; Firefox has several ways to invoke some functionality: - native commands in some menu (click, alt+letter navigation to reach), - native commands with keyboard shortcut (partially subset of previous), - native commands with keyboard shortcut not in any menu (e.g. excellent ctrl+shift+pgUp/Dn for reordering tabs) - native commands bound to context not in any menu (e.g. arrow keys when focus is on tab, shift+tab there), - native bookmarklet (entered, clicked in bookmarks toolbar, clicked in menu, searched in awesomebar, invoked by keyword in awesomebar), - custom button (extension), - extension menu popup item click, - extension keyboard shortcut, - context menu extension item, - other extension: gesture, VIMperatorish, greasemonkey... In ideal world I'd like to be able to see all native and extension provided commands in one place and review their invocation means (shortcuts, like Keyconfing). Even better if extension could provide, list and invoke all those commands. Command palette known from contemporary IDEs is also really great concept, BTW.
You need to log in before you can comment on or make changes to this bug.