Use 'a' key on keyboard to close tab in privileged urls

I’m trying to make an add-on that closes the current tab when the ‘a’ key on the keyboard is pressed using the tabs API.

What I’m doing right now is detecting if the key is pressed using content script and sending message to background script using runtime.sendMessage() where tabs.remove() is applied.

The problem is that content script won’t kick in for some domains like ‘support.mozilla.org’. Is there some way I can go around this by doing the whole thing in the background script?

I cannot use the commands API for this as the shortcut that I want is a single alphabet key and doesn’t include any meta-keys.

Any Ideas?

As already explained in the addons room on matrix, this is not possible. The intention of the commands API is to solve exactly your issue, but since the available keyboard shortcuts from the commands API are not acceptable to you there is no solution.

You could solve this by using software on your computer that triggers Ctrl + W when you press an arbitrary key.

What kind of software can be used for that? And would something with javascript itself be possible for this?

And I wonder how add-ons like https://addons.mozilla.org/en-US/firefox/addon/shortkeys/ and the numerous add-ons that provide vim keybindings like https://addons.mozilla.org/en-US/firefox/addon/vim-vixen/ manage to do it…

I was attempting something similar actually.

And I noticed that add-ons that use commands permission like https://github.com/mikecrittenden/shortkeys/blob/master/app/manifest.json t do not specify the suggested-key. Then how is the shortcut key mentioned?

For Windows I know of “auto hotkey” aka AHK for example that offers such functionality. I’m sure there are other solutions that also support other platforms.

You could do this with JS, assuming you had the appropriate C bindings for a runtime environment like node to have access to the respective system APIs.

They are usually built with in-page content scripts that capture key events at that level, which as you noted, does not work on privileged pages.

You can also set the key programmatically or make it unbound by default, but letting the user bind it if they want to use it.

There is one partial workaround - you can enable content scripts on those restricted domains (except for about:* pages and other extension pages).

  1. create new key “privacy.resistFingerprinting.block_mozAddonManager” in “about:config” page with boolean TRUE value
  2. in the key “extensions.webextensions.restrictedDomains” remove all domains remove domains like addons.mozilla.org and support.mozilla.org

This will however “reduce” security since addons will be able to access those domains. But I’m pretty sure there are no malicious addons doing this :smiley: (I mean, who would target such a small audience).

I’m sorry, this is no “reduction”. There are very good reasons these domains are blocked. The main reason I am aware of is privilege escalation, since you could for example intercept a user’s synced stuff had you access to the Firefox sync service, or install other extensions if you had access to the AMO APIs etc. So yes, this drastically reduces the security of WebExtensions. And just because it’s blocked by default doesn’t mean there aren’t payloads that check if they can exploit this vector for users that decided they wanted some feature that was blocked by this and made a (sadly) uninformed decision.

Further, this does not fix it for about: pages.

2 Likes

Well that does sounds much worse than I though!
OK let’s say removing only these two domains from the list:

support.mozilla.org
addons.mozilla.org

That should help with security, right? Still all addon installs has to be approved by the install popup so that should be ok…

Except that you still unlock uninstalls and querying currently installed extensions.