Where a Firefox default behaviour is overridden: the override should be plain, and documented

For example, from #189:

… New tab <kbd>Ctrl</kbd>-<kbd>T</kbd>

… moz-extension://f263e8e1-bc63-46fb-ad51-c59280fd8252/conex-options-ui.html

– no mention of <kbd>Ctrl</kbd>-<kbd>T</kbd> (or <kbd>Control</kbd>-<kbd>T</kbd>), and I assume that on Mac OS X there’s no mention of <kbd>Command</kbd>-<kbd>T</kbd>. Neither does https://addons.mozilla.org/addon/conex/ hint at an override. …

Plainness – in menus, for example

For the use case above, I don’t know whether WebExtensions APIs will allow the override by Conex to cause the keyboard shortcut to be:

• not presented alongside New tab
• presented alongside the relevant container in the submenu of New container tab.

A wild guess, without consulting Bugzilla@Mozilla: that’s the type of thing that should target 60, but might slip to 62 in Q3 2018.

Menu inconsistencies aside …

Any override should be:

1. documented at the preferences page for the extension; and
2. ideally, documented at https://addons.mozilla.org/addon/conex/ although whilst the extension is experimental 😃 I shouldn’t expect that page to be comprehensive or up-to-date.

Addressing point (1) should allow #11 to be closed.

Thanks 👍

[kesselborn]

so … the only action item that survived this discussion is the documentation of the override which I added to the options ui

[grahamperrin]

… Perhaps my current feeling is that conex is totally broken because of all the issues and weird behavior people report …

Far from totally broken!

Reality check, the framework within/alongside which you’re working. Three aspects, as I see it:

1. a relatively new technology (containers)
2. ten pages of issues for Mozilla’s extension
3. a set of APIs that’s somewhat gappy (WebExtensions).

That’s, like, a potentially challenging triangle 😃 so don’t beat yourself up.

For Conex: occasionally consider each issue in isolation (probably easier said than done); and occasionally prioritise.

Cheers