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/
(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.