Feature Request: A way to change the container of the current tab

(Boltwatts) #1


Many times when I have used containers, it became necessary to go through the exercise of opening a new container tab, copying the link of the current tab and pasting there to eventually open that website by default in that container. It would make it massively easier if there were a way to simply put the current tab into a container and set it as a default container without the hassle/workaround.



Move tab from container or to container

This is very popular feature request. (See the GitHub issue here)

The consensus on that issue seems to be to use the Context Plus extension.

(Jkingston) #3

Also see the explanation here:

(Graham Perrin) #4

A few months ago:

Continuing the extensions-oriented discussion in this topic:



Extension conflicts

When Conex is enabled, both Context Plus and Switch Container lose their ability to de-contain. https://github.com/kesselborn/conex/issues/38#issuecomment-330339534 notes:

… don’t really see the value of running “Context Plus” and taborama with tab movement enabled in parallel …

– a good point, but use of Switch Container can be swifter than Conex when dealing with multiple pages that either:

  • began in not the best container; or
  • leaked to an inappropriate container.

In any case, I have a gut feeling that an end to that extension conflict will come naturally when some of the thornier issues are resolved.

Last but not least:


(Graham Perrin) #5

Re: Mozilla bug 1323873 - Allow tabs to change user contexts when navigating

Thanks for reaffirming.

In the Outlook Web App (OWA) obfuscated URL + redirection use case at https://github.com/mozilla/multi-account-containers/issues/428#issuecomment-334981806 the first screenshot shows me aiming for no containment only because I know the sender etc. well enough to be certain that what’s linked need not be contained.

More commonplace OWA use cases will involve relatively careless clicks where the user does not require a context menu. In some such cases there will be dual perspectives.

Where I’m an onlooker (e.g. IT support with attention to privacy, security, phishing etc.) I’d like to see redirection to either:

  1. ideally traditional private browsing, although I don’t know whether a private tab can be in the midst of a window where any tab is non-private; or
  2. a container that’s conceptually private, and (@kesselborn please correct me if I’m wrong) I guess that’s somewhat in line with the experimental ‘private’ container that featured in https://github.com/kesselborn/conex/issues/61 (although we didn’t mention redirection in that context).

From the perspective of the end user – with or without me overlooking – it is, in my experience, less likely that a change of containment (or away from containment, to private browsing in the same tab) will be appreciated or understood.

Potentially tricky stuff!

(Graham Perrin) #6

To Daniel and/or Michael, if you’re here: did either of you intentionally fix that conflict?

Test results from around a week ago suggested that it’s no longer a problem :+1:

(Daniel Bornkessel) #7

yeah … I guess that was fixed with https://github.com/kesselborn/conex/commit/1825e8edb88013dd35c4eb3111c33fffe413cad8