@kesselborn @smichel17 and all – spun off from GitHub (for broader discussion) …
From New Tab always misinterpreted as New Container Tab … · Issue #56 · kesselborn/conex
… only one container will be visible at a time, …
Consider Mozilla bug 1323873 - Allow tabs to change user contexts when navigating in particular, from comment 10 by @jonathanKingston:
… about allowing a Tab to transition from one context to another on navigation. … isn’t about converting the current URL from one context to another. …
If that enhancement request will be implemented in Firefox, or in an extension – and if Conex will show no more than one container at a time – then what will happen when one tab in the midst of (say) a dozen, all of which relate to each other, undergoes a transition? Will that one tab disappear, leaving its eleven relations in the single visible container? Or will the window automatically transition to suit the one tab, and cause the user to lose sight of the eleven that were related?
What if the transitioning tab – with e.g. four transitions or more – is one of fifty tabs or more?
1323873 is partly what drove my question under Can we do something about the context menu entry? · Issue #711 · mozilla/multi-account-containers:
… Please, have I misunderstood the mock-ups? Or is the intention to encourage no more than one window per container?
Back to kesselborn/conex issue #56:
… the goal is to be a tab-group replacement …
A fine goal but re: https://github.com/mozilla/multi-account-containers/issues/336#issuecomment-305962454 (2017-06-03) etc. my use case is among those where it’s simply not possible to embrace the use of containers for tab management.
Folks, please note, that’s not a lack of appreciation of the qualities of Firefox containers.
Rather, it’s a recognition of what I see as the feature’s natural emphasis on containment without movement. More technically:
My workflows embrace rich, seamless movement – as is possible with combinations of extensions such as these: