New Tab _always_ misinterpreted as New Container Tab …

[grahamperrin]

open new tabs automatically in current tabgroup · Issue #11 · kesselborn/conex

Probably as a result of that, Control-T and (on a Mac) Command-T never produce a non-contained new tab. And when New Tab is chosen in the File menu, it's as if something else was chosen.

Whilst the change of interpretation will be appreciated by some users, it should be a user preference – not always enforced by the extension.

Related, for a different extension

Option to open new Tabs in the same Container · Issue #462 · mozilla/multi-account-containers

[kesselborn]

mmm ... yeah: that's currently a wanted behavior.
I am reluctant to add bazillions of options on the option page ... but perhaps I should think about it.
Thanks for the report

[grahamperrin]

Thanks. And I've been quietly .oO(thinking) that this might be somehow related to loady-leaky #58

[smichel17]

@kesselborn I think you should decide what you want the goals of this extension to be. Currently it does 3 things, any combination of which could be their own extension.

• Shows a list of containers and tabs in them
• Makes new tabs open in the current container
• Allows movement between containers

To whatever extent these features do not rely on shared logic, I would strongly suggest breaking them into separate extensions, so that users can mix and match as they please. That will also minimize the conflicts with other extensions that modify the same behavior.

For example, I'd love if containers on the go modified the behavior of <Ctrl-t>, rather than adding the <Alt-c> shortcut. How would that interact with conex today? If conex were broken into separate extensions, I could install the one for moving tabs between containers and the overview, but not the one that affects the behavior of <Ctrl-t>.

However, this would not make sense if the end goal for this extension is still to be a replacement for tab groups (ie, eventually, hiding tabs that are not in the current container -- more like chrome profiles).
If only a single container's tabs are shown at once, then it doesn't make sense that a new tab would open in anything but that container, so that functionality should be bundled.

[kesselborn]

@smichel17 great point and I don’t know why I missed that: yes: the goal is to be a tab-group replacement and only one container will be visible at a time, which is why new tabs are always in the current container.

[grahamperrin]

Thanks. Over to https://discourse.mozilla.org/t/-/15331/4?u=grahamperrin …

[grahamperrin]

@kesselborn I think quietly about this issue almost every day.

… reluctant to add bazillions of options …

I share the wish for not too many user preferences.

---

… new tabs are always in the current container.

On one hand: I reckon, if that behaviour can become a highly experimental preference – not a default – then large chunks of the rest of Conex can become non-experimental.

That's just my tester's instinct. (No relevant knowledge of coding or APIs.)

On the other hand: the current inflexibility probably does make it easier to identify bugs.

Elsewhere

From #68 (comment) (2017-10-22) under opening external links does not open url in contained tab anymore · Issue #68 · kesselborn/conex:

… Thinking about it: I am not even sure if this is a good idea … external programs ….

I'm thinking about both (a) this #56 and (b) nearby #68 in the context of:

• the current order of things at WebExtensions/TabHiding - MozillaWiki (2017-10-23)

– and related Mozilla bugs:

1. 1332447 - WebExtension API to hide the tabstrip (2017-01-19)
2. 1384515 - Provide an API for hiding and showing individual tabs (2017-07-26)
3. 1408053 - Show that tabs are hidden and all the implications (2017-10-12)
4. 1410548 - Tab hiding (2017-10-20)

Postscript

Of those four Mozilla bugs, 1408053 might have the greatest potential to reshape our thoughts.