UI for re-assigning an extension's command shortcut

VERIFIED FIXED in Firefox 66

Status

()

P2
normal
VERIFIED FIXED
3 years ago
3 days ago

People

(Reporter: bugzilla.mozilla.org, Assigned: mstriemer)

Tracking

(Depends on: 6 bugs, Blocks: 4 bugs, {dev-doc-needed, feature})

Trunk
mozilla66
dev-doc-needed, feature
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 66+, firefox66 verified, firefox67 verified)

Details

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

Attachments

(9 attachments, 1 obsolete attachment)

59 bytes, text/x-review-board-request
Details
59 bytes, text/x-review-board-request
Details
59 bytes, text/x-review-board-request
Details
59 bytes, text/x-review-board-request
Details
46 bytes, text/x-phabricator-request
aswan
: review+
Details | Review
46 bytes, text/x-phabricator-request
aswan
: review+
Details | Review
46 bytes, text/x-phabricator-request
Details | Review
46 bytes, text/x-phabricator-request
Details | Review
511.42 KB, image/gif
Details
(Reporter)

Description

3 years ago
Chrome has an UI to let the user customize command shortcuts. Presumably to make it match local keyboard layouts or to resolve conflicts with other extensions.

FF currently provides no way to change the commands.

https://stackoverflow.com/questions/16281037/configurable-keyboard-shortcut-without-using-content-scripts
(Reporter)

Updated

3 years ago
Blocks: 1240350
Component: WebExtensions: Untriaged → WebExtensions: Frontend

Updated

3 years ago
Priority: -- → P3
Whiteboard: [design-decision-approved]triaged

Updated

2 years ago
Duplicate of this bug: 1287093

Comment 2

2 years ago
Dropping a link to bug 1320332 for visibility: That bug is about offering APIs to WebExtensions to resolver conflicts in key registrations.
See Also: → bug 1320332

Updated

2 years ago
Blocks: 1325692

Updated

2 years ago
See Also: → bug 1337457

Updated

2 years ago
No longer blocks: 1240350

Updated

2 years ago
Depends on: 1342584

Updated

2 years ago
Blocks: 1342584
No longer depends on: 1342584

Updated

2 years ago
Duplicate of this bug: 1373909

Updated

2 years ago
Duplicate of this bug: 1389124

Updated

2 years ago
Duplicate of this bug: 1395153
Whiteboard: [design-decision-approved]triaged → [design-decision-approved]triaged [commands]
Comment hidden (me-too)

Comment 7

a year ago
I just accidentally closed Firefox 57 when I meant to close just a single tab. It's a shame, because I really liked my experience with Firefox 57 so far; the Achilles' Heel of Firefox 57 is the Ctrl+Q keyboard shortcut, which closes the entire Firefox application, sits next to the Ctrl+W keyboard shortcut, which closes just a single tab. This is very frustrating and jarring for user experience. What's the priority for this particular bug? When can users expect functionality to modify or disable keyboard shortcuts?

Comment 8

a year ago
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 bug 1325692, '[commands] Explicit support for overriding built-in keyboard shortcuts by WebExtensions'
- does not yet include this bug 1303384

Comment 9

a year ago
(In reply to Graham Perrin from comment #8)
> 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 bug 1325692, '[commands] Explicit support for
> overriding built-in keyboard shortcuts by WebExtensions'
> - does not yet include this bug 1303384

I think this bug is create a UI to manage the assigned commands, instead of an APIs to manage.

Comment 10

a year ago
As a user, it'd be much nicer not to need an extension for this. You have to trust extensions and their authors.
(Assignee)

Updated

a year ago
Depends on: 1421811

Updated

a year ago
Duplicate of this bug: 1422153
"Duplicate of this bug: 1422153" 
NO ! Bug 1422153 functionalities (proposed standard follow-up of keyconfig extension) are far more powerful than Bug 1303384 (that it may solve).
See http://forums.mozillazine.org/viewtopic.php?f=48&t=72994 the Keyconfig forum. Its 225 pages show many examples of codes attributed to key combinations by users.
(Assignee)

Updated

a year ago
Blocks: 1215061
A user of my extension has reported a bug ( https://github.com/arantius/uppity/issues/9 ) that this would resolve.

Comment 14

a year ago
Such a feature would be also very useful for users of Zotero since the CTRL+S shortcut collides with one of the fundamental action of this extension (saving a document), and I guess this can often happen so the users should be allowed to modify shortcuts according to their needs. See the discussion on Zotero forum (https://forums.zotero.org/discussion/68675/change-default-keyboard-shortcuts-on-firefox).

Comment 15

a year ago
I use FireFox with Google Docs, and I want Google Docs to be able to receive complex keyboard commands like Ctrl+Alt+Something, to do various tasks, such as to assign a paragraph style.

I use Firefox with LogMeIn, and when I am in a logmein remote control session, I want to use keyboard shortcuts like Ctrl-N and Ctrl-Q and I want those to go to the remote session I am typing on.  I want to be able to see and DISABLE all global keyboard shortcuts.

I use FIrefox with (continue ad infinitum).

Firefox is a browser. It's a multi-purpose tool.  Every single keyboard shortcut that exists that I can't disable or remap hurts me.

Quantum moved the ball back to about 2008 for me.   This browser is for surfing CNN and Reddit and not useable for me as a daily driver until I have total control over its keyboard shortcuts.

This should not be an extension. This should be something in about:config, or about:config.keyboard or something.

Comment 16

a year ago
Pretty much ditto to above.  Right at this moment I'm using ghost and nvim-ghost to edit this bugzilla report from vim.

I work in datascience and web development.  Chrome is ok, but I'm a big fan of FOI and FOSS and not having a hotkey for being able to quickly activate and externally edit from firefox is a massive cumulative drain on my day.  Every time I reach for the mouse, I'm thrown off my beat.

Just one more voice asking that you please make this very important feature a serious priority.
(In reply to skyleach from comment #16)
> I work in datascience and web development.  Chrome is ok, but I'm a big fan
> of FOI and FOSS and not having a hotkey for being able to quickly activate
> and externally edit from firefox is a massive cumulative drain on my day. 
> Every time I reach for the mouse, I'm thrown off my beat.

I don't want to pull things off topic but, to be fair to Firefox, that's a bit tangential to this issue as it *is* already possible to have such a hotkey.

While it doesn't integrate deeply enough with the editor to support synchronizing unsaved changes, withExEditor does it (Ctrl+Shift+u by default and customizable).

Comment 18

a year ago
I think the status can become 'Confirmed' right?

+1
(Assignee)

Comment 19

a year ago
My understanding for what is wanted for shortcuts (and is discussed here and in linked bugs) is this:

  * Change a shortcut for a command programmatically/with extension UI (bug 1421811).
  * Change a shortcut for a command through Firefox UI (this bug).
  * Change any shortcut in Firefox through Firefox UI (no bug/many bugs).
    * There are lots of bugs to add/remove shortcuts but not many seem to propose a UI for it. bug 588710 seems like the closest bug for this.
    * bug 1422153 is duped here and suggests this but also other stuff, that maybe shouldn't have been duped.
  * Support any shortcut I want—like escape, j or ]–in extensions (bug 1215061).
  * Overwrite a Firefox shortcut with an extension shortcut (bug 1325692).

All of these bugs are referenced here and this bug should have a fairly specific scope. Comment 0 is something we are planning but the timeline/UX is not clear to me right now. Everything else should be discussed in their corresponding bugs.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 20

a year ago
Here's how I understand it:

The ask is for a UI that allows the user to see and modify all of Firefox's native keyboard shortcuts.
The user needs to be able to add a new shortcut to a command, and to modify or remove the existing shortcut.

In Firefox 56-, this functionality was provided by the KeyBinder extension.

https://addons.mozilla.org/en-US/firefox/addon/keybinder/

I would expect the Firefox native UI to be very similar to the one provided by that extension (screenshots are on the extension page), including having having the commands sorted into sections, and having the ability to search.


Keybinder also showed some keyboard shortcuts created by extensions and allowed those to be re-bound - for example, the key to open the Feeds Sidebar in the extension of the same name.  I don't believe WebExtensions currently support those kind of global hotkeys anyway.

Comment 21

a year ago
And here's how I understand it:

The request is for a UI to display to the user and allow them to modify the keyboard shortcuts a web extension has specified using the command section of the manifest file.

Currently, a user has no standard way to discover or modify an extension's shortcuts, basically making the commands thing useless, and requiring extension authors to ignore it and implement shortcuts manually in a way they can allow the user to customise the shortcut.


As mentioned in comment 19, that appears to be what this bug is about. If you want to change all of Firefox's shortcuts, that should really be tracked in a separate bug. Maybe both issues will be solved with the same solution, but they are still separate issues.

For me, regardless of whether a global shortcut preference is added, I would like to see an extension's shortcuts appear at the top of the extension's settings page (and without the extension author needing to add anything).

Comment 22

a year ago
Okay, we definitely need to split this out into two bugs.

"Command shortcuts" is ambiguous; I always assumed it meant keyboard shortcuts for internal Firefox commands, but it could just as easily mean keyboard shortcuts for commands in WebExtensions.

Like you said, I'd imagine both issues would be solved through the same UI, but should be separate bugs.

Which one should be tracked by this bug, and which should be raised as a new one? 
Either way, the description of this bug needs to be reworded.
(In reply to Nameless Voice from comment #22)
> Which one should be tracked by this bug, and which should be raised as a new
> one? 
> Either way, the description of this bug needs to be reworded.

The scope of this bug is clearly stated by the component it is filed in, which is a WebExtensions component. For the generic UI, see the bugs that were linked in comment#19

Comment 24

a year ago
(In reply to Stephan Sokolow from comment #17)
> (In reply to skyleach from comment #16)
> > I work in datascience and web development.  Chrome is ok, but I'm a big fan
> > of FOI and FOSS and not having a hotkey for being able to quickly activate
> > and externally edit from firefox is a massive cumulative drain on my day. 
> > Every time I reach for the mouse, I'm thrown off my beat.
> 
> I don't want to pull things off topic but, to be fair to Firefox, that's a
> bit tangential to this issue as it *is* already possible to have such a
> hotkey.
> 
> While it doesn't integrate deeply enough with the editor to support
> synchronizing unsaved changes, withExEditor does it (Ctrl+Shift+u by default
> and customizable).

Sorry, I believe I was a bit unclear.  While I am talking about externally editing, it is insufficient for my needs to have a server spawning an editor as this process loop is too slow, and doesn't include numerous other extensions.  Technically, I can copy and paste, edit, save, and paste back to the browser as well.  Having the ability to activate other extensions on text area that maintain an active communication with the text area, and which communicate those changes to the editor in real-time, would be a more accurate description of my needs.

After looking at how to bind extensions to hotkeys, I found my way here.

Comment 25

a year ago
This bug is linked in ublock origin's tracker about missing / broken keyboard shortcuts, which broke in Firefox 56. It's odd that currently it is not possible for extensions to make use of keyboard shortcuts for their functionality.
https://github.com/gorhill/uBlock/issues/2870#issuecomment-322234217 + 3 duplicate tickets. Hope this get's addressed by Firefox. This bug has currently 58 votes and has been open for 2 years.
Comment hidden (offtopic)

Comment 27

a year ago
(In reply to Martin Giger [:freaktechnik] from comment #23)
> The scope of this bug is clearly stated by the component it is filed in,
> which is a WebExtensions component. For the generic UI, see the bugs that
> were linked in comment#19

In that case, we should use bug 588710 for the generic UI for Firefox-native controls.

Can someone rename this bug to make it clearer that it is about WebExtensions and not native Firefox functionality?
(In reply to skyleach from comment #24)
> Sorry, I believe I was a bit unclear.  While I am talking about externally
> editing, it is insufficient for my needs to have a server spawning an editor
> as this process loop is too slow, and doesn't include numerous other
> extensions.  Technically, I can copy and paste, edit, save, and paste back
> to the browser as well.  Having the ability to activate other extensions on
> text area that maintain an active communication with the text area, and
> which communicate those changes to the editor in real-time, would be a more
> accurate description of my needs.
> 
> After looking at how to bind extensions to hotkeys, I found my way here.

I understood your message to mean that you had gotten ghost and nvim-ghost working with Firefox, but it didn't have a hotkey to open/focus the editor. Specifically, that you were referring to this bug --> https://github.com/GhostText/GhostText/issues/113

I pointed to withExEditor because it demonstrates a workaround that allows some form of customizable keybindings right now which you might want to poke @bfred-it about.
(Assignee)

Comment 29

a year ago
I think the name was clear since this is filed in WebExtensions, but if it will keep things on topic I hope this helps.

Extensions can currently display their command shortcuts using the `browser.commands.getAll()` API to list them to users. If you think commands should be surfaced to users in other specific cases then feel free to file a bug about that. Currently sidebar shortcuts are displayed in the switcher. Browser action shortcuts could probably be displayed in a tooltip but I don't think that is the case right now.

The scope of this bug is well defined in comment 0, I don't think this bug needs more discussion right now. If you don't think this is going to solve your problem them adding to this bug is unlikely to provide a solution. You may want to look at the bugs linked in comment 19.
Summary: UI for re-assigning command shortcuts → UI for re-assigning an extension's command shortcut

Comment 30

11 months ago
In my opinion this is a very important feature and I cant understand why Mozilla ignore it. I also think the guys from Mozilla do a great job but their strategy/tactic to reach more people is not good. The biggest part of user come from "OS installs from a friend/vendor". So it should be the main target to improve and support the usability for power users. The power user will install Firefox on the computer of "normal dying people". Shortcuts, Tab Grouping, Web Development, Performance, Privacy, Security should be the main targets. "Why should I use Firefox if the IT-Professional tell me Chrome is "faster" and better?"

This problem could be ?easily? solved with an extra menu under settings "Shortcuts" and offer a fully customizeable shortcut menu. We only need a Shortcut API and an integrated Firefox Shortcut API to customize.

Example:

[Del. Shortcut]   [KEY]                  [Source]               [Description]     

[X]               [STRG+T]               [Firefox Core]         [Open a new Tab]
[X]               [STRG+ALT+F1]          [Tree Style Tab]       [Open TST Sidebar]
[X]               [STRG+ALT+F1]          [Tree Style Tab]       [Open TST Configuration]
[X]               [STRG+SHIFT+ALT+X]     [Feedbro]              [Open Feedreader]
[X]               [                ]     [           ]          [               ]

[[Add new Shortcut]] [[Restore standard Shortcuts]] [[Delete All Shortcuts]]  (Buttons - self explanatory)

[ ] Allow new installed Addons to change this configuration.
[ ] Allow Addons to change Firefox Core shortcuts.  (Checkboxes - self explanatory...)


Key: Self defined up to 4 keys. (Click in and push combination)
Source: Name of the source which provide the shortcut [Dropdown menu of available Sources (FF Core, FF Dev Bar, Addons as ex.]
Function: Offer the provided Shortcuts by the chosen source [Dropdown menu - depending on Source]

Firefox Core need to offer the basic Shortcuts. The Addons only need to provide a "Description" of each provided shortcut and an internal function which is linked to the selected keystroke. Source = Addon Name

A warning after Addon installation would be fine.

Simple - Efficient - Future proof and all the shortcut issues are gone.

Comment 31

11 months ago
A hardcore enhancement would be an option to add something like "Open Website" and insert Adress under "Description".

"Shift-X" to open a self defined "daily visited" website as example? (Google, Webmail, News, Mobility Connections...) I'm sure there will be some more ideas and the fight for shortcuts will end.

Sorry for double comment.

Updated

11 months ago
Duplicate of this bug: 1458131

Comment 33

10 months ago
A GUI would be great, but will take long. Alterative is to implement prefs, or Webextension API that can change these prefs for all shortcuts FF is currently using. E.g. "browser.shortcuts.closeWindow;Alt+F4" and extensions like https://addons.mozilla.org/de/firefox/addon/shortkeys/?src=search would be able to change those.

Updated

9 months ago
Product: Toolkit → WebExtensions
(Assignee)

Updated

9 months ago
Assignee: nobody → mstriemer
Priority: P3 → P2

Comment 34

8 months ago
I want to second the focus of Comment 20 and also several other comments about interference of shortkeys with other applications. The mentions here are far from complete. (The most irksome thing for me is trying to use Emacs in the Guacamole remote desktop gateway and having interference with ctrl+n, ctrl+t, and ctrl+w.)
It is surprising to me that complaints about this go back as far as 2 years on this bug and sometimes even further on related bugs, but there still has not been a resolution.
See also e.g.,
https://bugzilla.mozilla.org/show_bug.cgi?id=1215061#c69
https://bugzilla.mozilla.org/show_bug.cgi?id=1320332#c12
The issue is in other bug threads as well, and is something for which other people are searching for solutions in other online fora.
I don't think this should be left for random extension writers but rather should be a high priority fix.
(Sorry I am a newbie to Bugzilla so I'm not sure how things actually do ultimately get fixed; this is the one place where I was able to find that the bug is marked as assigned to somebody and given a priority. I don't know exactly what the priorities mean; P2 sounds pretty good, but I do hope somebody can resolve this soon.)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Comment 39

8 months ago
These patches are WIP, when attempting to overwrite an existing command (like ctrl+w) the existing command is executed (in this case the tab is closed). This isn't ideal, and I'm not sure if we want to support overwriting commands right now (although it would seem reasonable).

Regardless, I'd say having the tab close if you try to set something to ctrl+w is a blocker for now.

Comment 40

8 months ago
(In reply to Mark Striemer [:mstriemer] from comment #39)
> These patches are WIP, when attempting to overwrite an existing command
> (like ctrl+w) the existing command is executed (in this case the tab is
> closed).

Bug 1325692 is about overriding built-in shortcuts, FYI.
Comment hidden (advocacy)
(Assignee)

Comment 44

7 months ago
MozReview-Commit-ID: KeZsoB6qj88

Comment 45

7 months ago
I tried out your patches and posted some review comments.

Your isSystem validator is stricter than what is allowed in the manifest file.
By default, I am able to override Cmd-Q on macOS (https://addons.mozilla.org/en-US/firefox/addon/disable-ctrl-q-and-cmd-q/ ). The UI complains about the use of this shortcut, but when blurring, it still reverts to the previous Cmd-Q shortcut.
I hope that you fix this by allowing built-in shortcuts such as Cmd-Q/Ctrl-Q rather than blocking all "system" shortcuts.

(In reply to Mark Striemer [:mstriemer] from comment #39)
> Regardless, I'd say having the tab close if you try to set something to
> ctrl+w is a blocker for now.

On macOS, the default action of Cmd-W is successfully prevented already.
On Linux, I can prevent the default action using a system listener in the main process:

// document is the browser.xul document
Services.els.addSystemEventListener(document, "keydown", e => {e.preventDefault();}, true);

I tried to register a listener in the content process, but that did not work, possibly because of the "reserved" attribute on the key.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIEventListenerService#addSystemEventListener()
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Attribute/reserved


It is probably a good idea to ask others whether this is a good approach before committing to it though. There might be a footgun that I'm unaware of.
Comment on attachment 9004759 [details]
Bug 1303384 - Part 1: Extract extension commands management to a module r?aswan

Andrew Swan [:aswan] has approved the revision.
Attachment #9004759 - Flags: review+
Comment on attachment 9004760 [details]
Bug 1303384 - Part 2: Move some extension shortcut utils to ShortcutUtils r?aswan

Andrew Swan [:aswan] has approved the revision.
Attachment #9004760 - Flags: review+
(Assignee)

Updated

6 months ago
Blocks: 1490366
Attachment #9004761 - Attachment description: Bug 1303384 - Part 3: Add a manage shortcuts page to about:addons r?aswan → Bug 1303384 - Part 4: Manage extension shortcuts page r?aswan
The part 5 patch here makes command description localizable, setting dev-doc-needed for that specific bit.
Keywords: dev-doc-needed

Comment 51

5 months ago
Related bug (perhaps duplicate): https://bugzilla.mozilla.org/show_bug.cgi?id=1411795
Attachment #9010490 - Attachment is obsolete: true
Are you still planning to land this on 65?
Flags: needinfo?(mstriemer)
(Assignee)

Comment 53

4 months ago
I think I've run out of time for 65 on this one. The patch has been brought up to date with inbound but with reviews needed and soft freeze around the corner probably best to wait for an early 66 landing.
Flags: needinfo?(mstriemer)
Attachment #9004761 - Attachment description: Bug 1303384 - Part 4: Manage extension shortcuts page r?aswan → Bug 1303384 - Part 3: Manage extension shortcuts page r?aswan
Attachment #9010491 - Attachment description: Bug 1303384 - Part 5: Localize command descriptions r?aswan → Bug 1303384 - Part 4: Localize command descriptions r?aswan
(Assignee)

Comment 54

2 months ago

Looks like this is about ready. There were some concerns over non-Latin keyboards in review which look like are okay, but Gijs is looking to do another review tomorrow.

Flags: needinfo?(gijskruitbosch+bugs)

Comment 55

2 months ago

r+ on phab. :-)

Flags: needinfo?(gijskruitbosch+bugs)

Comment 56

2 months ago
Pushed by mstriemer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f4697feb30df
Part 1: Extract extension commands management to a module r=aswan
https://hg.mozilla.org/integration/autoland/rev/d1eacc92d6d6
Part 2: Move some extension shortcut utils to ShortcutUtils r=aswan
https://hg.mozilla.org/integration/autoland/rev/456b9b7963eb
Part 3: Manage extension shortcuts page r=aswan,Gijs,flod
https://hg.mozilla.org/integration/autoland/rev/77c0cf8378df
Part 4: Localize command descriptions r=aswan

Updated

2 months ago
Depends on: 1520119

dev-doc-needed? It would be nice to add this somewhere on the "commands" page.

For reference, you have to go to about:addons -> Extensions -> Keyboard shortcuts (which is a button next to the settings gear).

Wouldn't it be better to move it to a separate tab, to create more visibility?

Updated

2 months ago
Depends on: 1520123

Comment 59

2 months ago

you have to go to about:addons -> Extensions -> Keyboard shortcuts

And how to go back?

(In reply to gwarser from comment #59)

And how to go back?

You just click the "Extensions" item in the left panel again. This is the same as going back to the overview from an extension details/options page.

Comment 61

2 months ago

When you go to the details page, UI clearly changes and it's like another page, so going back is natural.

Going to shortcuts UI does not change page too much and I expected to have "back" or "toggle" button just under cursor where "Keyboard Shortcuts" button was.

Why not move shortcut UI to the extensions details page?

Updated

2 months ago
Depends on: 1520144

The current approach also means that the extension shortcuts page isn't linkable. Compare, e.g., how about:preferences uses fragments like about:preferences#search to identify its different pages.

(In reply to quasicomputational from comment #62)

The current approach also means that the extension shortcuts page isn't linkable. Compare, e.g., how about:preferences uses fragments like about:preferences#search to identify its different pages.

This isn't due to the current approach, instead it is how the add-on manager behaves in general. None of the add-on manager pages are linkable.

Comment 64

2 months ago
Pushed by mstriemer@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/41184f42f451
Part 5: Fix TODO and string in .ftl r=flod
No longer blocks: 1520068
Depends on: 1520068
(Assignee)

Updated

2 months ago
Depends on: 1520164

This seems worth a release note in 66 beta.
How about this wording:
WebExtension keyboard shortcuts can now be managed or overridden from about:addons

relnote-firefox: --- → 66+
Flags: needinfo?(ddurst)
Keywords: feature

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #66)

This seems worth a release note in 66 beta.
How about this wording:
WebExtension keyboard shortcuts can now be managed or overridden from about:addons

Added to Nightly release notes

Comment 68

2 months ago

Bug:

What happens:
If I try to enter "Ctrl+F4" there (on Linux; German QWERTZ keyboard) it closes the tab of about:addons.
However, when you reopen it, the hotkey is set anyway.

What should happen:
Show this error "cannot overwrite Firefox/Nightly built-in commands" and do not save hotkey.

Comment 69

2 months ago

Linkable site:
Also I agree with some commenters that it would be great if I could link from my WebExtension to this page, so I can have a button "Customize hotkeys" that takes the user to that site, so they can adjust the hotkey there.

Another feature requests:
IMHO you should list add-ons without any hot keys/commands defined at the bottom of the list. If I, as a user, want to customize the hot keys of an add-on, I do not want to search for it, respectively scroll over 20 add-ons where I cannot even set a hot key, but find it directly, so I am faster and not so much annoyed.

Note:
Also note that some add-ons also show a huge amount of defined hot keys there (https://flagfox.net/viewtopic.php?f=3&t=726), so this may be a little confusing, but I also see no way to dynamically add/request new commands in the WebExtension API, as you always have to pre-define them in your manifest.json.

Comment 70

2 months ago

If I try to enter "Ctrl+F4" there (on Linux; German QWERTZ keyboard) it closes the tab of about:addons.
Not for me, latest Nightly, installed addon Shortkeys and entering "Alt+F4" for close tab leads to the expected behavior (tab is closed and FF window closure is prevented). Need to inform Peter about that.

Guess this also fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1325692 , although the user enters the shortcut and not the webextension in the example above.

(In reply to rugk from comment #68)

Bug:

What happens:
If I try to enter "Ctrl+F4" there (on Linux; German QWERTZ keyboard) it closes the tab of about:addons.
However, when you reopen it, the hotkey is set anyway.

What should happen:
Show this error "cannot overwrite Firefox/Nightly built-in commands" and do not save hotkey.

This is noted in bug 1520068 which is about exactly the same keyboard input handler.

(In reply to sgl4kn from comment #70)

Not for me, latest Nightly, installed addon Shortkeys and entering "Alt+F4" for close tab leads to the expected behavior (tab is closed and FF window closure is prevented). Need to inform Peter about that.

Ctrl+F4 is something different than Alt+F4 though. Different places where they are handled. My guess would be that this shouldn't be working (i.e. Alt+F4 shouldn't be assignable). I can't assign Alt+F4 (browser closes and shortcut is never saved), so I assume my OS is inserting a stronger handler than yours.

Comment 72

2 months ago

Ctrl+F4 is something different than Alt+F4 though. Different places where they are handled. My guess would be that this shouldn't be working (i.e. Alt+F4 shouldn't be assignable). I can't assign Alt+F4 (browser closes and shortcut is never saved), so I assume my OS is inserting a stronger handler than yours.

Case in point: Under X11, Alt+F4 is handled by the window manager and the applicaton never receives KeyPress/KeyRelease events for it.

It can usually be rebound in the window manager's hotkey settings. (eg. ~/.config/openbox/... or the "KWin" section of KDE's Global Keyboard Shortcuts control panel... which, in all honesty, I'd been hoping this bug would take design inspiration from in providing a unified, searchable configuration UI for all registered hotkeys, both built-in and extension-defined.)

Updated

2 months ago
Blocks: 1521389

Comment 73

2 months ago

(In reply to rugk from comment #69)

Note:
Also note that some add-ons also show a huge amount of defined hot keys there (https://flagfox.net/viewtopic.php?f=3&t=726), so this may be a little confusing, but I also see no way to dynamically add/request new commands in the WebExtension API, as you always have to pre-define them in your manifest.json.

Filed bug 1521389 for this. Please fix this before this new GUI hits release.

(Assignee)

Updated

2 months ago
Depends on: 1521826
(Assignee)

Updated

2 months ago
Depends on: 1522227
(Assignee)

Updated

2 months ago
Component: Frontend → Add-ons Manager
Product: WebExtensions → Toolkit
(Assignee)

Updated

2 months ago
Depends on: 1522229
(Assignee)

Updated

2 months ago
No longer depends on: 1522229
(Assignee)

Updated

2 months ago
Depends on: 1522230

Updated

2 months ago
Blocks: 588710
(Assignee)

Updated

2 months ago
Depends on: 1522757

(Sorry, relnote lgtm. Clearing NI.)

Flags: needinfo?(ddurst)
(Assignee)

Updated

2 months ago
Depends on: 1524296

Comment 75

15 days ago

Can you please confirm whether this is still targeted for 66?

Flags: needinfo?(mstriemer)
(Assignee)

Comment 76

15 days ago

This is still targeting 66.

Flags: needinfo?(mstriemer)

Comment 77

3 days ago
Posted image Bug1303384.gif

This issue is verified as fixed on Firefox 66.0-build3 (20190314174725) and Firefox 67.0a1 (20190317213820) under Win 7 64-bit and Mac OS X 10.14.1.

The new UI for assigning shortcut keys in the command field of the extension, is displayed in about:addons.

Please see the attached video.

We can mark this bug verified as fixed since has landed in Fx66, with the mention that the rest of the bugs are considered as future improvements for Fx67, according to Relman.

Updated

3 days ago
Status: RESOLVED → VERIFIED
status-firefox66: fixed → verified
status-firefox67: --- → verified

Thanks so much for the hard work :D

You need to log in before you can comment on or make changes to this bug.