1521389 - New WebExt keybinding GUI shows empty placeholders; don't show hotkeys without descriptions

Status: RESOLVED DUPLICATE of bug 1521826

(WebExtensions :: Frontend, defect)

Description

[Dave Garrett]

The new WebExtension keyboard binding GUI added in bug 1303384 should not show empty bindings. Doing so just makes things messy and confusing for the user, and these placeholders unfortunately cannot be removed as they are required to allow for arbitrary user-set hotkeys using the WebExtension command API.

Reporting this based on a Flagfox addon user reporting seeing the result of this here (also linked to from their bug 1303384 comment 69):
https://flagfox.net/viewtopic.php?f=3&t=726
Quoting my reply from there:

---

Flagfox has had the ability to set custom hotkeys for all actions for about 9 years. (since Flagfox 4.0 in Feb 2010) When Mozilla set the addon universe on fire with the mandatory switch to the WebExtension API a bit over a year ago (Nov 2017), they did so without fully implementing many longstanding capabilities, only slowly adding a few things back piecemeal, and only over the past half year. For about 7 months after the old APIs were banned, no keyboard shortcut customization API existed at all; it was impossible to do in Firefox 57-59. Firefox 60 (May 2018) FINALLY got an API to change a keyboard binding, though just that; there's no API to check if a potential binding is valid or otherwise in use. This was enough for me to be able to re-implement hotkeys in Flagfox 6.1 (July 2018), however I had to do lots of futzing to make it work. It's not a good API. What you can see in your screenshot is the result of one of Mozilla's poor decisions in creating their API for this. Simply put, the API only allows changing an existing binding, not actually creating new ones. It just explodes if you try and do something obvious like let a user create their own action and set a hotkey for it. The only way to handle this is pretty simple: just pre-define a pool of empty hotkey bindings and then re-assign them as needed. I just went with a big round number of 100 plus the "?" one used exclusively for test-setting hotkeys from the options to see if they're valid at all.

Seeing as the keyboard binding definitions are completely empty, and only exist to workaround Mozilla's deficient API, as far as I'm concerned, this is a Mozilla bug. If they're going to add a GUI to edit addon shortcuts half a damned year late after adding an API to update addon shortcuts half a year late, they should make it not show this cruft.

---

Please just don't try to show bindings that have nothing but an ID and no description or shortcut. It probably shouldn't show any without a description, regardless of having a shortcut; internal IDs shouldn't be dumped out to the GUI like that. Any addon that actually wants to and is capable of working with this new GUI should simply be required to set a description via the existing API (as Flagfox already does).

It'd probably also be better to just allow me to add a flag to the addon manifest to state that Flagfox has its own GUI to handle this, and Firefox can just show a button to open Flagfox's options page. It shouldn't break anything to have things settable in two places, though.

Also, expose the validation capabilities that had to be written for this new GUI in the actual API. It should have been added at the same time as adding the ability to update bindings (as should be obvious given the fact that Mozilla had to create a validator in order to write their own GUI here). If Mozilla needs it in order to use the API, then addon developers need it for the same reason.

(edited to fix autoformatting because Bugzilla is dumb now)

Comment 1

[Mark Striemer [:mstriemer]]

Thanks for pointing this out.

The history of your extension isn't really related to this bug, and the negativity isn't exactly helpful. Because of that, I've filed bug 1521826 to work on a solution for this.

You list more changes you'd like at the bottom of your message, if you'd like to propose those features be added you should file a new bug for each one individually. Ideally those bugs would describe what the feature is and why it would be helpful in a brief manner.

Comment 2

[Dave Garrett]

(In reply to Mark Striemer [:mstriemer] from comment #1)

The history of your extension isn't really related to this bug, and the negativity isn't exactly helpful.

Negativity? That's a disheartening way to put it. If you're going to interact with this heavily neglected area of the codebase, you're going to have to expect frustrated developers. Don't take it personally; Mozilla simply lost most of its support among the addon developer community. This is of course off-topic, but then again you've closed this already.

Because of that, I've filed bug 1521826 to work on a solution for this.

You can of course do that, even though it's against normal Bugzilla procedure, but it's a strange bit of rudeness. It's always been recommended against creating explicit duplicates, as it breaks the normal relational metadata of a bug as well as CCs.

You list more changes you'd like at the bottom of your message, if you'd like to propose those features be added you should file a new bug for each one individually. Ideally those bugs would describe what the feature is and why it would be helpful in a brief manner.

No.

Again, please do not take my tone personally. Simply put, the "no obligation" part of the Bugzilla etiquette goes both ways. I've been on Bugzilla for 12 years, and I know which bugs I could file would be worth my time and get action, and which I have low expectations. I'm going to have to file bugs for issues like this, where a new feature in development was pushed to Trunk without full testing in the top 50 addons and things break. (it happens, unfortunately) On the other hand, I'm not going to waste time, effort, and sanity trying to convince anyone to do other straightforward fixes/improvements if they already decided not to.