webextensions command API keyboard shortcuts not triggered when webcontent such as text edits are focused
Categories
(WebExtensions :: General, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: original.roju, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:94.0) Gecko/20100101 Firefox/94.0
Steps to reproduce:
A user of my addon Most Recent Tab reported a bug (https://github.com/thePaulV/Most-Recent-Tab/issues/12), that the keyboard shortcut doesn't work as expected when focused on a text field on a site. From this comment (https://bugzilla.mozilla.org/show_bug.cgi?id=1624738#c1) this behaviour seems to be by design, but I can't find a bug tracking this specifically.
- Set an addon's keyboard shortcut to something like alt-q on MacOS
- Open a tab to a site with a text area (e.g. bugzilla)
- Focus on the text area
- Press the shortcut (e.g. alt-q)
Actual results:
- A character is inserted ("œ")
Expected results:
- The shortcut triggers and the addon does something
Comment 1•3 years ago
•
|
||
This is handled at widget level, we can't really guarantee a lower level platform code doesn't already handle a specific shortcut.
This just a platform restriction in Firefox. We should perhaps document that [alt] is not a very viable combinatino for extension shortucts on OSX.
Comment 2•3 years ago
|
||
This just a platform restriction in Firefox. We should perhaps document that [alt] is not a very viable combinatino for extension shortucts on OSX.
Actually, let's make this bug about adding a warning to developers and/or users.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Alt-something is a standard shortcut on macOS to type special characters. It would be against user expectations to allow extensions to override that by default.
If a user wants to use the same shortcut everywhere, then they could manually change the shortcut as explained at https://support.mozilla.org/en-US/kb/manage-extension-shortcuts-firefox
If you'd like to set a default, you could use a different shortcut for a specific OS by default via the commands
key in the manifest.json file.
The downside to this is that it would change the shortcut for existing users who are used to the old shortcut. An alternative to that is to use the commands.update
API to change the shortcut programmatically, e.g. via (optional) extension-specific UI.
To be clear, my addon does set a reasonable default using the commands key in the manifest. This user wanted to customize it to that alt- based shortcut using the built in interface for customizing addon shortcuts. I just tested it out again, and the built in shortcut selector in Tools\Addons page will happily let you set an alt- shortcut on Mac even though it seems like it's a bad idea. Perhaps the real fix is to prevent that, or at least warn when a user does it?
Comment 5•3 years ago
|
||
A warning sounds like an acceptable work-around.
Would you mind filing a feature request for that (and reference this bug for context)?
Description
•