Open Bug 1325692 Opened 8 years ago Updated 1 month ago

[commands] Explicit support for overriding built-in keyboard shortcuts by WebExtensions

Categories

(WebExtensions :: General, defect, P5)

52 Branch
defect

Tracking

(Not tracked)

People

(Reporter: robwu, Unassigned)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: [design-decision-approved] triaged)

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/commands says the following: > 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. This appears to not be true in Firefox. I don't see any logic that checks whether the shortcut is already registered at http://searchfox.org/mozilla-central/source/browser/components/extensions/ext-commands.js Moreover, I created an add-on that successfully blocks the default actions of the Ctrl-Q and Command-Q shortcuts (which normally cause Firefox to quit) by registering Ctrl+Q/MacCtrl+Q and Command+Q in manifest.json: https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/ Can you confirm that this is the expected behavior, and if so, update the documentation?
Summary: commands API documentation → commands API documentation incorrectly asserts that default shortcuts cannot be overridden
Flags: needinfo?(amckay)
I just removed that paragraph based on your add-on. I think we should probably think about if we want to have a permission for overriding built-in commands, so altered the bug title accordingly.
Flags: needinfo?(amckay)
Priority: -- → P5
Summary: commands API documentation incorrectly asserts that default shortcuts cannot be overridden → Prevent overriding built in keyboard shortcuts
Whiteboard: [design-decision-needed] triaged
I think simply overriding is always a bad idea, even if there is a permission. Firefox should finally get a proper UI for configuring keyboard shortcuts where conflicts are visible and resolvable in a clever way.
+1 for a better UI. Follow bug 1287093 for it.
I believe that with a proper UI (or API), it should be possible to allow WebExtensions to override the shortcut. So I'm adding bug 1240350 and bug 1320332 as dependencies.
Depends on: 1303384, 1320332
Bug 1303384 is about providing a UI for re-assigning command shortcuts. Probably the only thing this adds to that bug is showing the built in commands so you can see when a shortcut is overriding a build in shortcut.
Whiteboard: [design-decision-needed] triaged → [design-decision-approved] triaged
Adjusted summary to more accurately reflect the purpose of the bug.
Summary: Prevent overriding built in keyboard shortcuts → [commands] Explicit support for overriding built-in keyboard shortcuts by WebExtensions
Ctrl-Q cannot be overridden on Linux - https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/reviews/854938/ This behavior is inconsistent across platforms :(
See Also: → 1267145
Is it known why this works on some platforms but not Linux?
I just ran into this after installing nightly on my MacBook Air and my Arch machine. Needless to say, plugins that use any shortcuts are nigh unusable on Arch.
[Tracking Requested - why for this release]: I hereby nominate this bug for Firefox 57 per the instructions in https://wiki.mozilla.org/Bugmasters/Marking_bugs_for_the_Firefox_57_release This bug causes data loss for users of Firefox 57 on Linux. Because the "Keybinder" extension will not be ported to WebExtensions, users who do not downgrade to the ESR (Firefox 52) must rely on the "Disable Ctrl-Q and Cmd-Q" extension, which doesn't work in Linux. Thus an accidental Ctrl+Q press when reaching for Ctrl+Tab to change to the next tab or Ctrl+W to close a tab results in loss of unsubmitted data entered into forms on other tabs. Affected users include all users of Firefox 57 for Linux who regularly use the keyboard to navigate among tabs. Do we have telemetry on the fraction of users who press Ctrl+W or Ctrl+Tab?
Removing flags, this API is not going to be written in time to for Firefox 57.
(In reply to Andy McKay [:andym] from comment #11) > Removing flags, this API is not going to be written in time to for Firefox > 57. Hello Andy. Is it possible to get a commitment to fixing it post FireFox 57 since it is a platform inconsistent behavior?
I just lost some data *again* due to Ctrl-Q. It is so frustrating.
Bug 1215059 - (webextensions-additional-apis) [meta] Extend WebExtensions with custom APIs so more legacy add-ons can be ported <https://bugzilla.mozilla.org/show_bug.cgi?id=1215059> - includes bug 1215061, 'Better keyboard shortcut support' - does not yet include this bug 1325692
Temporary workaround: Go to about:config and search for "quit". Enable browser.warnOnQuit and browser.showQuitWarning , so you'll at least the "do you want Firefox to save your tabs for the next time it starts?" message instead of having Firefox disappear in a poof. *DO NOT* click "Do not ask next time" when you actually do want to quit Firefox - this popup window will save your life every time you accidentally press Ctrl+Q. However, it's good to hear that the required API is currently being worked on, thanks!
(In reply to Vivia Nikolaidou from comment #15) > Go to about:config and search for "quit". Enable browser.warnOnQuit and > browser.showQuitWarning. That does not work, though: https://bugzilla.mozilla.org/show_bug.cgi?id=502908
(In reply to Jan Tojnar from comment #16) > (In reply to Vivia Nikolaidou from comment #15) > > > Go to about:config and search for "quit". Enable browser.warnOnQuit and > > browser.showQuitWarning. > > That does not work, though: > https://bugzilla.mozilla.org/show_bug.cgi?id=502908 Oh, thanks for the heads-up! I haven't upgraded to 57 yet because of another plugin blocking me, but for 56 this works (for me), even with the third-party plugin disabled. Maybe the showQuitWarning is what actually does the trick, it's not an actual "do you really want to quit?" but "do you want to save your tabs?", but at least it does the job. That said, I'd appreciate if someone could try it on FF57 and let me know if it's still working, but I also understand it's too risky to try :)
Just upgraded to Firefox 57 and I can confirm that the workaround still works. Might be that browser.tabs.warnOnClose also has to be true, but it's something!
(In reply to Vivia Nikolaidou from comment #18) > Just upgraded to Firefox 57 and I can confirm that the workaround still > works. Might be that browser.tabs.warnOnClose also has to be true, but it's > something! It only works in specific cases, see the linked bug.
(In reply to Jan Tojnar from comment #19) > (In reply to Vivia Nikolaidou from comment #18) > > Just upgraded to Firefox 57 and I can confirm that the workaround still > > works. Might be that browser.tabs.warnOnClose also has to be true, but it's > > something! > > It only works in specific cases, see the linked bug. Agreed, but still, better than nothing at all IMHO. :)
> That said, I'd appreciate if someone could try it on FF57 and let me know if it's still working I tried on Nightly (FF 59), doesn't work for me.
Dexter, this is your one reminder that Bugzilla is our professional working environment as much as it is our issue tracker, and that abusive comments of any kind will not be tolerated. I encourage you to read the Etiquette and Contributor Guidelines: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html ... and to take them to heart. If you've got a contribution to make to this or any bug that will move it towards a resolution, feel free to make it. If you contributions continue in this vein, however, my next step will be to suspend your account. Thank you.
> Do I look like I care about your professional working environment? You do not, so you will no longer be permitted to participate.
Vivia Nikolaidou wrote in comment 17: > I'd appreciate if someone could try it on FF57" Default on Firefox 57 on Xubuntu 16.04 LTS using US keyboard layout: browser.showQuitWarning default boolean false browser.warnOnQuit default boolean true Action: Ctrl+Q Result: Quit Session restore Expected result: about:config returns to the list of preferences Actual result: about:config returns to the "This might void your warranty" interstitial Change settings: browser.showQuitWarning **modified** boolean true browser.warnOnQuit default boolean true Action: Ctrl+Q Result: "Do you want Firefox to save your tabs for the next time it starts?" As for the five cases in bug 502908 comment 40: 1. No alert with 1 page open No problem, because Ctrl+W and Ctrl+Tab won't cause accidental Ctrl+Q presses 2. "When Firefox starts" set to "Show your windows and tabs from last time" Problem, as I've seen a few sites on which session restore fails to restore form state. 3. browser.warnOnQuit not modified Problem, as this preference is not discoverable. 4. No dialog in Private Browsing Problem. 5. Browser will be restarted No problem. May become a problem in the future if Firefox follows Windows 10 in performing unattended restarts.
I'm on FF 58, ArchLinux, and I can confirm that this plugin to disable Ctrl-Q does not work: https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/ I also tried toggling browser.showQuitWarning to "true", as well as having my browser.warnOnQuit set to its default "true" value as well. But Ctrl-Q continues to close my browser without any warning. This is very frustrating and happens several times per week. Why doesn't Firefox let users override or disable the default keybindings?
Last time I ran Firefox 57+ on Windows the keyboard shortcut for closing the browser was Ctrl+Shift+Q. Why does the Linux build differ in this regard, quitting the browser with Ctrl+Q? Ctrl+Shift+Q is a much saner choice.
I get the same on Ubuntu 16.04 running Firefox 58 as mentioned in Comment 27. For me I'm always bumping Control-Shift-W when trying to hit Control-W. I've also tried setting showQuitWarning and it also will not prompt me when I bump that sequence.
Unfortunately there are no workarounds to this bug. Mozilla needs to document the WebExtensions API as mentioned by Rob Wu in this bug and implement the behavior on Linux. (Or they just need to remove this terrible shortcut, but that seems unlikely; see Bug 52821 which has been open and biting users for 18 years.)
(In reply to eddie.dunn from comment #28) > Last time I ran Firefox 57+ on Windows the keyboard shortcut for closing the > browser was Ctrl+Shift+Q. Why does the Linux build differ in this regard, > quitting the browser with Ctrl+Q? Ctrl+Shift+Q is a much saner choice. Platform convention. On Linux, it's typical for graphical programs to interpret Ctrl+Q as "quit". (In reply to Andrew Eikum from comment #30) > Unfortunately there are no workarounds to this bug. I'm not aware of a workaround that's specific to Firefox, but if you'd like to disable Ctrl+Q for all applications (including Firefox), I found you can do that by defining a global shortcut that maps Ctrl+Q to the command "/bin/false". In KDE I do this via System Settings -> Shortcuts -> Custom Shortcuts. Presumably there's a GNOME equivalent.
(In reply to Botond Ballo [:botond] from comment #31) > I'm not aware of a workaround that's specific to Firefox, but if you'd like > to disable Ctrl+Q for all applications (including Firefox), I found you can > do that by defining a global shortcut that maps Ctrl+Q to the command > "/bin/false". > > In KDE I do this via System Settings -> Shortcuts -> Custom Shortcuts. > Presumably there's a GNOME equivalent. The simplest "proper" way to make a Firefox-specific workaround would probably be to replace "/bin/false" with a script which checks the active window's title against a blacklist and then re-emits the event directly to the window, bypassing the global key grab if it's not on the list. I haven't had time to look up the "re-emit the event" part, but a slightly more racy solution using what I do already know would be to take this "react to changing window focus" example code... https://gist.github.com/ssokolow/e7c9aae63fb7973e4d64cff969a78ae8 ...and replace the `handle_change` function with something that grabs Ctrl+Q when Firefox becomes focused and releases it when Firefox loses focus. Here is an example of using XGrabKey via the same python-xlib API: https://gist.github.com/Neoklosch/843fbd34cd50e53216b4 ...and here are the XLib docs for `XGrabKey` and `XUngrabKey` functions that `grab_key` and `ungrab_key` correspond to: https://tronche.com/gui/x/xlib/input/XGrabKey.html https://tronche.com/gui/x/xlib/input/XUngrabKey.html
Hmm... this bug is marked wontfix for Firefox 57. Firefox 58 is now out, and it doesn't seem like this bug has had any traction. Will there be any push for this WebExtensions API to work on Linux for Firefox 59?
(In reply to Stephan Sokolow from comment #32) > The simplest "proper" way to make a Firefox-specific workaround would > probably be to replace "/bin/false" with a script which checks the active > window's title against a blacklist and then re-emits the event directly to > the window, bypassing the global key grab if it's not on the list. What you’re describing is neither “simple” nor “proper”. (For one thing, there would be a race window between the key press and the time when the script gets to check the window class. During that time, the user could have switched to a different window.) Not many end users are going to be able to implement this workaround. The proper solution is to provide a shortcut customization mechanism in Firefox. Many comments here focus on hating Ctrl+Q. While that is a major annoyance, I’d like to remind that there are many other use cases for overriding built-in shortcuts. For example, a user who wants to emulate Emacs keybindings would need to override C-x and C-c. I personally would like to be able to rebind Ctrl+P to Print Preview, and change Alt+B to pop up the Bookmarks Menu from the button on the toolbar rather than from the main menu, and possibly unbind F7, F11 and F12 which my cats seem to press much more often than I do.
I don't want to take this more off-topic than it already has gone, so I'll be brief and stop with this. 1. "simplest" does not necessarily mean "simple" and I put "proper" in quotes to contrast it with "kill off Ctrl+Q globally". (I do intend to write such a workaround when I have time, and I plan on using Xlib and Rust to further minimize the real-time window for any races I fail to avoid.) 2. I fully agree with you that a shortcut customization mechanism is desirable and I have wanted one since the pre-Phoenix days when I was running Mozilla Suite. Likewise, menu customization is something I've wanted to be official since Mozilla Suite and probably half of my userChrome.css rules are either either hiding context menu entries entirely, hiding the icons on addon-provided context menu entries, or hiding Page Actions such as #pageAction-panel-emailLink which deserve to be pushed out to disable-able extensions at least as much as "RSS icon as a page action" and the various "share" extensions.
(In reply to Yuri Khan from comment #34) > > The proper solution is to provide a shortcut customization mechanism in > Firefox. > > > Many comments here focus on hating Ctrl+Q. While that is a major annoyance, > I’d like to remind that there are many other use cases for overriding > built-in shortcuts. For example, a user who wants to emulate Emacs > keybindings would need to override C-x and C-c. > Also, some hardcoded hotkeys suck immensely on non-english layouts, an there's no way to change them. For example the quick findbar hotkeys are '(single quote) and /(slash). But for me to access them, I need to press shift+1 and shift+6. Also this obviously clashes with binding shift+f1/f6 with a different function. Or at least used to until it was possible via an addon. (this second problem was aggravated with hotkey addons since there are a bunch of characters on my layout that can be accessed via ctrl+alt+something or altgr+something, which resulted in non-functional hotkeys. eg: ctrl+alt+c/altgr+c might be read as "&" but neither combination would work when I press it)
One workaround to the specific problem of the "Control-Q or Control-Shift-W Firefox quitting without prompting" problem mentioned in Comment 0 would be to create a test page that implements the beforeunload[1] function and leave that page loaded in a pinned tab in the browser. This forces Firefox to prompt the user before quitting with "This page is asking you to confirm that you want to leave - data you have entered may not be saved." giving them an opportunity to abort the quit. Here's the page I use to do this : https://gene1wood.github.io/sandbox/prevent_browser_quitting.html [1]: https://stackoverflow.com/a/6801553/168874
(In reply to Andy McKay [:andym] from comment #1) > I just removed that paragraph based on your add-on. I think we should > probably think about if we want to have a permission for overriding built-in > commands, so altered the bug title accordingly. I restored the phrase to the article because I wasted hours discovering the hard way that I cannot override built-in shortcuts. For example, on Windows, I cannot override Ctrl+P to let users choose whether Ctrl+p shows the Preview page or the Print dialog. https://github.com/jscher2000/control-p-preview
This is a really frustrating bug when you are trying to 'lockdown' what a Linux end user can access. What is the time-frame on a fix Mozilla?
Shortcut remapping is probably not what you're looking for, if you're hoping to create a kiosk-like experience from Firefox. It seems likely our upcoming policy engine work will be a better fit for that. https://blog.mozilla.org/futurereleases/2018/01/11/announcing-esr60-policy-engine/
(In reply to Mike Hoye [:mhoye] from comment #40) > Shortcut remapping is probably not what you're looking for, if you're hoping to create a kiosk-like experience from Firefox. I believe the idea is to avoid closing the browser by mistake.
For me this has very little to do with accidentally closing the tab, bur rather customizability to make the browser right for me. I like keyboard driven interfaces, and in particular Vim-like bindings. But Vimium has no power as soon as the domain is *.mozilla.org because of what I regard a bad decision from the Firefox devs. And while switching tabs works fine with Vimium, if I have [tab1][about:blank][tab2], I can not switch between tab1 and tab2 because of the about:blank in between (which makes Vimium bindings lose control). I hate that, it breaks my experience with Firefox which used to work so well. It's a shame, and would be a great feature to give us back.
(In reply to Lindhe94 from comment #42) > ... I like keyboard > driven interfaces, and in particular Vim-like bindings. But Vimium has no > power as soon as the domain is *.mozilla.org because of what I regard a bad > decision from the Firefox devs. On that point, Firefox 60 is expected to have a preference that lets users unprotect Mozilla domains from extensions with "all hosts" permission. https://dxr.mozilla.org/mozilla-beta/source/modules/libpref/init/all.js#5114 But I assume there will still be severe restrictions with respect to about: pages.
FWIW, as a GNU/Linux user, I was able to successfully change the "undo closed tab" binding and unbind the Ctrl-Q binding using AutoKey (https://github.com/autokey/autokey). It's an X11 application, though, so no luck for Wayland users.
(In reply to Gene Wood [:gene] from comment #37) > One workaround to the specific problem of the "Control-Q or Control-Shift-W > Firefox quitting without prompting" problem mentioned in Comment 0 would be > to create a test page that implements the beforeunload[1] function and leave > that page loaded in a pinned tab in the browser. This forces Firefox to > prompt the user before quitting with "This page is asking you to confirm > that you want to leave - data you have entered may not be saved." giving > them an opportunity to abort the quit. > > Here's the page I use to do this : > https://gene1wood.github.io/sandbox/prevent_browser_quitting.html > > > [1]: https://stackoverflow.com/a/6801553/168874 So simple and effective, yet so very twisted that users have to resort to dirty hacks like this. Platform inconsistencies should be a major concern instead of pushing the open bug from version to version.
Blocks: 1215061
Product: Toolkit → WebExtensions
I wrote a little script for block ctrl+q only in Firefox with xbindkeys, so we can use ctrl+q on others Linux apps. git clone https://castorcorp.eu/kstor/Firefox_ctrlQ_disabler.git Instructions is in the README or on the project page : https://castorcorp.eu/kstor/Firefox_ctrlQ_disabler Hope it can protect some mental health.
(In reply to K-stor from comment #48) > I wrote a little script for block ctrl+q only in Firefox with xbindkeys, so > we can use ctrl+q on others Linux apps. > > git clone https://castorcorp.eu/kstor/Firefox_ctrlQ_disabler.git > > Instructions is in the README or on the project page : > https://castorcorp.eu/kstor/Firefox_ctrlQ_disabler > > Hope it can protect some mental health. I also did something like that but did my best to minimize hacky tricks in its design so, if anyone would prefer something that's written using python-xlib and tries to be as efficient as possible, it's here: https://github.com/ssokolow/firefox_ctrlq_fix (The system requirements say Python 2.7, but that's really just "I didn't have a Python 3.x port of python-xlib to test against". It was originally intended as a proof-of-concept before a Rust version, but I've just been too busy.)
Hi all, there’s a lot of off-topic and advocacy chatter in this bug, which makes it hard to find information relevant to implementation. We’re currently discussing if this is something we want to support and/or assign to the engineering team since it seems like most folks want to disable existing shortcuts, not override them. I’m going to restrict comments on this bug until we have a better sense of what the next steps will be.
Restrict Comments: true
See Also: → 1654403
Blocks: 1692205
No longer blocks: 1692205
No longer blocks: 52821

Because many people here seem to particularly care about disabling CTRL+Q - This is now possible with the preference browser.quitShortcut.disabled in Firefox 87+. (Bug 52821)

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 80 votes and 134 CCs.
:robwu, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(rob)
Depends on: 1555620
Flags: needinfo?(rob)
See Also: → 1911798
You need to log in before you can comment on or make changes to this bug.