Multi-account-containers: Consider a tab context menu option to convert a normal tab to a container

[pmac]

I often click a link from an external app and a normal tab opens, but I'm logged into the web app in a container. I'd like to be able to just convert the tab rather than copy the URL, close the original tab, open a new container tab, and paste the URL.

[groovecoder]

Thanks @pmac

[hasanen]

Perhaps it isn't that big of job add a feature to convert tab from container to another within this?

[gwynnarth]

This might be a good enough solution for #325 I think.

[maverick74]

This is a very important feature that will ease job a LOT, from my point of view :).

Thumbs up for this :)

[smichel17]

Privacy-concerned user here. I would prefer that external links not all be opened in the same context. So, I would not consider this a good enough solution for #325.

Would you consider allowing users to specify which container they would like to open each new tab in?

Example interface

First, add a setting akin to the one for downloads, Open external links in with the options of selecting a default container or Always ask me where to open links. Screenshot for reference:

edit after a little discussion: I do not think it is important to be able to choose a default container. The below can be modified to choose between Open external links outside of containers and Ask me which container to open external links in.

If Always ask me where to open links is selected, links get pre-filled into the URL bar with the cursor placed at the end, with drop-down options to open it in either the global namespace or a specific container. Quick pixel art mockup:

[aleth]

This would be very useful, possibly together with "Move all tabs to container..." (similar to what exists for bookmarks).

While containers were primarily designed to keep identities compartmentalized, one should not underestimate how many people will use them simply for tab management (e.g. as a replacement for tab groups).

[smichel17]

I think there are two related but definitely different questions here: one is about privacy and the other is about convenience.

Privacy

• The problem: It is difficult to keep profiles separate because it is hard to control what container an external link is opened in.
• A solution: Add the ability to choose which container a tab is opened into.
• This is a duplicate of #325.
• Moving a tab to a new container after it has been opened is not a solution; by that point, the separation of containers has been compromised.

A great example of the privacy problem just happened to me: I was in my development container and went to create an account on http://discourse.mozilla-community.org/. I put in my email address and sent a confirmation email, opened my email client, clicked the confirmation link... and confirmed my account outside of a container. Ooops.

Convenience

• The problem: My tabs are unorganized, and I'd like to organize them.
• A solution: Add the ability to move tabs between containers
• The reason it's easy to confuse this and the privacy problem is that tabs coming into the default container causes clutter in addition to the privacy issue. Two problems, same cause.
  
  
  
  • There are other ways tabs can get cluttered besides external links so I think it is still valuable even with the privacy problem resolved with a solution like I proposed above.
  
  
• While the wording is a bit confusing, #317 is talking about this convenience problem -- @aleth's comment about using them for tab management.

I suggest this issue be renamed and focused in on the privacy problem, and discussion about the convenience problem can take place in #317.

[gwynnarth]

Too bad one cannot upvote on a comment. I agree with @smichel17's analysis above.
I would just add to it that tabs opening in a wrong Container might be also a convenience problem, not only privacy problem.

For example: if I try to open a work-related GDocs link in a Default container (where I am logged on my private Google account) it will fail because I am not permitted to do so. I have to reopen the link somehow in the Work container where I am logged to my corporate account. Another example would be a link to something on Facebook (profile, photo... whatever) - I am logged in only in my Facebook container so in Default container I will get login page. In that scenario, where we talk about "semi-trusted" links the result is simply inconvenience because opening in Default container will not yield expected result. For that problem the ability to move tabs between containers post-factum is, in my opinion, good enough.

As for security and privacy I think I personally would like to handle this like that:

• Create a new "Untrusted" container.
• Set it as a default container for external links.
• Configure the container's security rules so that it does not retain any data when container is closed (for that we need to have per-container security settings, something a'la #314).

At least for me, the above scenario is a perfect balance between convenience (I don't have to choose the target container each time) and security (the "Untrusted" container by definition contains no sensitive information).

[smichel17]

Too bad one cannot upvote on a comment.

"Upvotes" are just thumbs up reactions. Click the smiley in the upper right of a comment.

For that problem the ability to move tabs between containers post-factum is, in my opinion, good enough.

Most of the time, probably. Sometimes when you try to go to a page meant for logged-in users it'll redirect you to a login page without including a redirect back to the page you were on (or it will store that information in a cookie, which won't be transferred when you move that tab into another container). For example, I tried to copy-paste the mozilla discourse link into a new tab in the correct container, but it expired after I followed it the first time, so I had to re-send it.

As for security and privacy I think I personally would like to handle this like that:

-snip-

I will point out, the "Untrusted" container could actually just be no container (the default context), and you could configure it not to accept cookies, retain history, run js, etc. So I guess I should revised my comment above to say "A solution" instead of "The solution." (Although, I personally prefer my solution to (or in addition to) the "secure default container" one.)

[gwynnarth]

Thanks @smichel17 for the hint about upvoting! :)

While of course I could configure Default container to behave like you described that wouldn't save me from creating a 'Trusted' or 'Private' (or 'Whatever' really) container that would override these settings - because I do want my cookies retained for most websites. At the moment I treat Default container as my 'Private' container where I am logged in to all my non-work-related site (this is of course just one way to use it).

All in all I think it is easier to create one 'Untrusted' container and configure it like I described above than override the default browser policy for X other containers. Mozilla could even preconfigure such Untrusted container to make it easier for non-power-users to adopt such scenario.

Both scenarios can and should coexist if your proposed solution gets implemented - and everyone would be able to pick their favorite :)

PS. In my ideal world I would be able to alternate easily between the two scenarios - by default links are opened in Untrusted container and if I alt-click it then it allows me to choose which container to use. Or the other way around. Unfortunately that's not going to be possible since it requires OS support or third-party app support. Not going to happen :(

[aleth]

I agree with @smichel17's https://github.com/mozilla/testpilot-containers/issues/311#issuecomment-284116146 - I just filed #336 before seeing the new comments here, which overlaps with what he wrote.

[MurzNN]

IMHO most of users use containers not for serious security reasons, but for easy switch profiles in services (for example, corporate and home logins in Google and Facebook). And errors when you open wrong container happens very often - you see wrong login and want to switch it. So ability to switch container of already opened tab will do this in more comfortable way.

P.S. Maybe at first we can solve this issue via separate extension - is this possible? If any want, it can install it, by default behavior will keep like now - without ability to change container of already open tab.

[Stis]

OP's title. I really need this simplicity, and i use it lots of times per day with Multifox right now.

I understand some may be concerned by security, but since I use Multifox a lot, i'm already used to pay attention to which profile/container my external will open. Losing simplicity I have right now for security... no, I prefer to stay vigilant. It's a good rule.

[jonathanKingston]

@smichel17 you talk about "Add the ability to choose which container a tab is opened into." which is a sound solution for the privacy problem. However it comes at the cost of harming convenience, if every link a user had to choose a container they are likely to suffer from "alert blindness" and just click any rather than making a good decision. I think once you can assign a URL to a container and you don't have cookies in a different containers we could make this simpler. For example:

• Open example.com in a work container.
• Example.com links to shopping-site.com.
• Browser shows a list of options to choose the container to go into before opening the link.
• User selects shopping and the new tab is opened as shopping.
• User visits another site linking to shopping-site.com and browser would choose shopping by default
• If a user right clicks and chooses a different container for shopping-site.com the browser would always show the choice screen when there are multiple the user has viewed the site in.

This would give users the privacy but also keep the convenience for less frequently used sites.

"Always ask me where to open links" is an option I would get behind certainly.

@MurzNN yes most of the containers work that has happened will be possible in an extension when the API changes we needed hit stable: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contextualIdentities

[smichel17]

@jonathanKingston agreed on all counts. Choosing which container to open a tab into is one solution of several to the privacy issue. If it were chosen, it should come along with a preference to be disabled and always open into the default container.

[aleth]

@jonathanKingston Some thoughts:

Isn't this bug (at least according to the description) arguably just about the simplest case (moving a tab from the default container to a different container)?

Shouldn't the default behaviour be to open links from a tab in container X also in container X? I suspect anything else is pretty confusing to the user.

I'm not sure "assigning a URL to a container" helps all that much, as e.g. it won't be useful if you use containers to have two different Google accounts logged in at the same time. It'll be a useful feature for some user workflows but not others.

[jonathanKingston]

So I am currently experimenting with #306 which allows a website to be assigned to a container.

I'm not sure "assigning a URL to a container" helps all that much, as e.g. it won't be useful if you use containers to have two different Google accounts logged in at the same time. It'll be a useful feature for some user workflows but not others. - @aleth

I'm currently not approaching this yet, we would need ideas on how to solve this.

Isn't this bug (at least according to the description) arguably just about the simplest case (moving a tab from the default container to a different container)? - @aleth

This is a bug related to changing the container the current tab is, the issues are often discussed together however they are separate.

agreed on all counts. Choosing which container to open a tab into is one solution of several to the privacy issue. If it were chosen, it should come along with a preference to be disabled and always open into the default container. - @smichel17

Currently the user has to opt in to "Always Open in This Container" and I am working on a privacy warning for users who want to be warned from clicking a link on evil.com (personal) -> workworkwork.rihanna.com (work) which users can disable also. The warning would happen pre-navigation before the browser has sent the user to the new page.

---

The issues here however are fairly different to those of #306. When a user has logged in by mistake in "No container" or work email in a personal container we likely will need to clear cookies, history and various other things. Clearing cookies for a whole tabs existence is likely way to heavy handed but it's also potentially very difficult to do cleanly.

For example google.com might load auth.google.com but the user might have analytics.google.com cookies already that they had from previous visits. There is also the problem of the global suffix list too where clearing taylorswift.geocities.com cookies wouldn't be intended when clearing cookies for belieber.geocities.com.

/cc @groovecoder going into a meeting now (just didn't want to loose all the above)

[MurzNN]

At now we can use separate extension Context Plus from Michael Westbom for quick switching container of already opened tab in Firefox 53+. Thanks to @totallymike!

[Stis]

Context Plus is just a little workaround. You can't switch context of a new tab. And it works by deleting the tab and creating a new one with the new context, which totally destroy the purpose of using Tile Tabs at least.

EDIT: i said it doesn't work for new tab, but taking the time to think about it, yes, it's better. Just old habit with Multifox where a new tab always has the context of the active tab. Since with Containers you choose the context when creating a new tab, it's ok.

[MurzNN]

@Stis, yes - Context Plus is only easy workaround, but at now this is much better that nothing. So I use it already in my work and wait when this feature will be available in Firefox Containters core/

[totallymike]

Unfortunately, you can't change the context of a tab, at least so far as my rudimentary research revealed, which is why I reconstruct the tab in the new context.

The ability to choose context when a new tab is being created is something I'd _love_ to have. Too many websites have an authentication flow that leave the redirect target in the session or something, meaning that if we were to switch contexts on a tab sitting on that login screen, it would become useless.

As for Tile Tabs, I wonder if it's possible for my plugin to communicate with that plugin. If there's more stuff I could preserve, I'd love to.

Context Plus is something I threw together in an hour while staring at the web extension docs for the first time. I'm glad some people are getting use out of it though :)

[MurzNN]

Too many websites have an authentication flow that leave the redirect target in the session or something, meaning that if we were to switch contexts on a tab sitting on that login screen, it would become useless.

My use case: I have 3 containers (Home, Work1, Work2) that already have successfull auth cookies. I receive link via external IM (Pidgin), for example, to Google Docs document - it opened in default "Home" context with "Access denied" error.

Now via Context Plus I can quickly switch context via context menu to "Work1" and look the document, without closing this tab, opening new container tab manually and copy-paste link to it.

[pmac]

Context Plus is something I threw together in an hour while staring at the web extension docs for the first time. I'm glad some people are getting use out of it though :)

Might be a quick hack, but it's a really useful one. It'd still be nice to have native support for this, but in the interim this is a huge improvement. Thanks so much!

[groovecoder]

Converting a normal tab to a container tab is/was related to #325 and thereby #311. We just released a fix for #311.

https://twitter.com/KingstonTime/status/849333366684082176

If the new "site-assignment" feature means you don't feel like you need to convert normal tabs to container tabs so much, can you please comment back here and/or remove your 👍 from this issue. We'd like to know if this issue is still higher priority than #336 and/or #119.

[Stis]

I like this new feature, i definitely have some sites i only use in certain context.
Too bad the right clikc sub "Open Link in New Container Tab" doesn't show on bookmarks.
And in bookmarks, it'd be nice to have a visual indicator to know if the bookmark will open in a specifiec context or not. Back ground of the context color, or the icon, i don't know, just a little thing, to know.

But i really would see what "Context Plus" tried to bring to us.
But the way it works now is not perfect at all. I need it like it was on Multifox.
To do that, no submenu on right click on the tab.
No new tab when clicking a context in Containers icon.
I need to change the context on the fly when clicking a context in containers icon, without destroying the tab to create a new one, but of course refresh the page with the new context.

It's not to be picky, it's just because destroy to recreate completely break the way i use Multifox with Tile Tabs.

That done, i don't see what to ask more. It'd be perfect, and i love you for doing all this great job, i was so scared to lose Multifox.

To finish, yes, it's more important to me than #336 or #119.
Concerning #336, i usually sort my tabs by site more than contexts. And hiding them, even temporary, i'd prefer the old Panorama than that.
And #119, i'm happy the way it works right now. CTRL+T or clicking "+" icon for no context new tab, middle click for same context, and keeping shift+click for new window.

[pmac]

My use case might be a bit unusual, but I find site-assignment both useful and not... I have some sites that I use in multiple containers because I need to be two different users (work and personal), and others that are always a certain kind (shopping e.g.). So while it's a great new UX improvement, it's not the whole thing.

That said, I'm also a keyboard navigator, so #119 would be very nice for me. I'm getting by just fine with Context Plus, so I'd say it's lower priority for me personally, but finding Context Plus was an accident of being involved in these issues on Github, so I'm guessing it's not a solved problem for a lot of people.

[smichel17]

@groovecoder The more I observe my own habits, the more I'm convinced of my analysis in https://github.com/mozilla/testpilot-containers/issues/245#issuecomment-287631854. Excerpt:

The real problem here is that we force the user to pick a context before they enter the URL.

I seldom open a new tab thinking "I want to do something in [some container]!" I open a new tab thinking "I want to visit [some site]!" THEN, once I've opened the tab and typed the URL, I think about what container this belongs in.

Right now this works great for links. I can right click a link, and choose to open it in a container tab. But when I copy-paste a link, or open in an external application, or want to open the current URL in a different container, the workflow just doesn't work for me.

The context plus addon helps, but is still more awkward than a native solution like I proposed above (I'm not wedded to that interface, just the idea of choosing a container after I've typed the URL).

edit: that is to say, I still think this feature is the top priority, although I also hope I'll soon be able to replace the tab groups addon.

[a2sheppy]

This is an important feature that will probably make or break adoption of the feature. Right off the bat, when you first start using Firefox with containers enabled, if you already have a lot of open tabs, you'll want to move them into the proper containers so that you can make proper use of containers. With no way to do that, odds are good people will just not bother to use it. This is in fact why I only marginally use it; because getting all my stuff into containers means re-opening everything from scratch.

In addition, even once you're using it, there are still too many ways to wind up with a tab that's not in a container but needs to be moved into one. If you open a page on a site you haven't configured to automatically open into a container, for example, it could be in the wrong container (or not in one at all). Of you've opened a new window and immediately gone to a container.

Or, most of all, perhaps, a tab is sent to your browser from another device. Who knows what container it'll wind up in... :)

[MichelZ]

For me, Containers is mainly a replacement for the now abandoned Multifox extension.
This functionality to move tabs between Containers was an essential feature that I was using frequently.

[happyGNU]

The first thing I thought when using this feature was, "how can I send the current tab to a container?". Please support this 😃

[rxmxr]

Like others, I'm here because Multifox died with v53.

I have many gmail accounts (some for work, some personal, etc.) and with Multifox I could use them all at once. Gmail claims to allow you to use multiple accounts in multiple tabs, but it works poorly and often closes you out of all accounts unexpectedly.

I also have multiple Amazon accounts...home use and multiple for different businesses. Again, Multifox was perfect for this. I could switch between/among identities and often the same link could be used to pop me into the same page in Amazon, but a different account. Same thing with eBay. Same with knowledgebase software that we use for different businesses.

Here's another use case, similar to one posted above about a link to google docs (this just happened to me): I received an email from eBay, but it went to an email address in container X. I need to open that email in container Y. The only way to do it is to copy the URL, open a new tab in container Y and paste. But if I could click the link and then switch containers, I'm in business.

For this reason, assigning URLs to containers does not help me.

This is why "send this tab to container" does help and it's why the Multifox toggle was a miracle for me. I used it countless times a day.

I was thrilled to discover containers...but the inability to move tabs from container to container is a huge drawback for me, which "assign URL to container" does not solve.

Thanks!

[saboxerman]

Yes, yes, yes please! Like rxmxr, I manage 3 eBay accounts, an Amazon account, and much more that Multifox made doing so much easier! I've put off updating my work computer as I found on my two laptops that it is difficult to do what I need to do without Multifox.

This feature would be a dream and I could finally update my work computer's FireFox!

[jeremiahlee]

I occasionally open a URL in a generic tab or the unintended container. Please add a "reload tab in container > [available containers]" option in the right-click context menu.

This would be especially useful for sites I have multiple accounts on, where the "Always Open In This Container" feature is not a solution.

[jonathanKingston]

This is possible in the super beta: Sea containers

• We are fixing the icon issues caused by test pilot, my extension doesn't implement the fixes we do here.
• Right clicking gives this option:
  
• The context menu comes from the browser, the icons are also missing (raising a bug now)

[the8472]

It's currently not possible since here is no API (not even browser-internal) to change the context ID of a tab. One can create a new tab and close the old one but then one obviously loses back-navigation, opener etc.

I have requested platform support for this in bug 1323873 but atm it's considered low-prio.

[grahamperrin]

… 1323873 but atm it's considered low-prio.

https://github.com/mozilla/testpilot-containers/issues/336#issuecomment-305962454 notes that 1323873 has been priority 3 (not low) since 2017-02-28, and:

With no-one assigned to 1323873, I doubt that the enhancement will be made before the 2017-11-14 release of Firefox 57.

[the8472]

priority 3 (not low)

My understanding is that P3 is backlog (low) and P5 is never unless someone volunteers.

[grahamperrin]

Thanks @the8472 I would never have guessed that from the part of the wiki page to which Bugzilla refers. there may be some confusion about priorities for the Bugzilla project, and priorities for products such as Firefox. https://wiki.mozilla.org/BMO/UserGuide/BugFields#priority is updated accordingly.

[the8472]

That wiki page links to https://wiki.mozilla.org/Bugmasters/Process/Triage#Weekly_or_More_Frequently_.28depending_on_the_component.29

[jonathanKingston]

@the8472 that is my understanding of how we categorise bugs now yeah. However from our view within the team I suspect it should be P5 (P4 is currently not used - not sure why).

[jonathanKingston]

I also think we should WONTFIX this too and suggest the install of ContextPlus.

[Stis]

Because it would be impossible to at least incoroporate ContextPlus?

Oh, and since I saw the webextension version of Tile Tab, I don't really care about the "destroy and recreate" part.
But switching context is till a must have. So, if ContextPlus can be incorporated... :]

[jonathanKingston]

@Stis no it's compatible, I just don't think it is part of our primary goal here in that it doesn't help privacy.

Oh, and since I saw the webextension version of Tile Tab, I don't really care about the "destroy and recreate" part.

Do you have a link? I'm a little confused.

But switching context is till a must have. So, if ContextPlus can be incorporated

It's a must have for tab management. It isn't for people who want privacy. I think we can safely just say install two extensions for those users. (especially as this one might become native)

[the8472]

It isn't for people who want privacy.

But it is, see comment 1 of the bugzilla entry for privacy-related examples. One fairly straight-forward use would be spawning new, disposable containers on link navigation whenever the top frame's domain changes.

[jplatte]

spawning new, disposable containers on link navigation whenever the top frame's domain changes

This sounds like it would break oauth.

[jonathanKingston]

@the8472 reading through the bug again this sounds a lot like you are after new ways to assign URLs into a container? Would that sound correct?

Have you used this feature of the current experiment at all?

[the8472]

@jplatte

This sounds like it would break oauth.

What I posted here was merely a simplified example of one possible use-case. If you're trying to shoot down my argument, please read the linked comment at least. It draws a more detailed picture

My point is that the basic building block of changing tab contexts is needed to build more complex features on top of it.

[the8472]

@jonathanKingston

No, that would only be part of what I want.

Domain-based containers are fine for pages which require a persistent identities.

But for read-only content I also want more ephemeral containers that are created automatically, not based on a whitelist. Those containers would be spawned and destroyed without user interaction, simply based on a set of rules that trigger on page navigation.

In the bugzilla bug I'm actually asking for an API so I can code this for myself, but of course I wouldn't mind if such a set of features were part of the test pilot addon.

[jonathanKingston]

@the8472 right ok so....

no API (not even browser-internal) to change the context ID of a tab.

This is the feature we don't really ever want to do, it's out of scope and very hard to solve.

ephemeral containers that are created automatically, not based on a whitelist.

Currently you can create a container and delete it at the end of the session with the APIs we have. That could be made a little cleaner however it would be enough to prototype with, I have done a few experiments with this before.
You can't however remove this from containers menus etc which makes spawning lots of containers or extension specific ones a little ugly.

This specific Github bug is more about converting the current tab a user has... that sounds less like what you are after despite your previous comment.

changing tab contexts is needed to build more complex features on top of it.

I'm not really sure why you need to change the tabs context, it certainly introduces privacy leaks rather than improvements? Copying a URL into an ephemeral container I can see being more useful for increasing privacy. However converting cookies and history etc would likely cause a lot of breakage. What are you expecting?

We should probably discuss this on Bugzilla as it's super out of scope of this experiment really.

[jplatte]

@the8472 Sorry, I didn't just want to shoot down your argument. Looking through the last few comments here and what exactly you are talking about (the bugzilla link) it seems like this issue is going completely off-topic though (as @jonathanKingston noted too, just as I was writing this).

Given that there is already an extension ([Context Plus]) that reloads a tab in a different container, it seems like you could build the more complex features you want on top of that, right?

[the8472]

@jonathanKingston

This specific Github bug is more about converting the current tab a user has...

Well, to me automatic change-on-navigation and manually changing are more or less the same thing, at least as far as the underlying machinery needed is concerned.

And other bugs have been duped here, thus I am commenting here.

it certainly introduces privacy leaks rather than improvements

Not if you change to the correct context upon tab navigation and the history would automatically change back when you navigate back.

Let's say I want to google for a video of a conference talk.

1. I am on github, logged in. maybe in some container, maybe the default container
2. Ctrl+L to reach for the URL bar in whichever tab I am in right now
3. g <talk title> video keyword search, goes to google)
4. addon cancels navigation and goes to about:blank instead
5. addon creates a new container and assigns it to current tab
6. addon navigates current tab with new container to the google search
7. after clicking on the link in the google result it goes to google's redirect and then to the target page (youtube)
8. addon detects navigation to youtube. I have a youtube account BUT it is a deep link to youtube, so it again assigns an ephemeral container (the persistent youtube-container only gets assigned when navigating to https://youtube.com/ directly, without path or when already in that container)
9. we are now on youtube in yet a different container, without google cookies from the previous container or any persistent identity
10. back, back, back. we are on github again, in the github container

However converting cookies and history etc would likely cause a lot of breakage. What are you expecting?

I want to change the context ID only for future history items, not past ones. When going backwards it would have to go back to the old container too. Moving the tab's current contents could be implemented on top of that simply by changing the tab's future context and then navigating to the current URL, which will be reloaded in the new container.
That's why the ability to change the context ID is a building block, you can do many things with it.

@jplatte

Given that there is already an extension (Context Plus) that reloads a tab in a different container, it seems like you could build the more complex features you want on top of that, right?

No, since that would be a different tab. I want containers to work seamlessly when navigating within a tab to minimize friction. Opening a new tab, losing history, having to think about whether I am in the right container are all hurdles that make using containers more cumbersome. Privacy features should not be cumbersome.

[the8472]

Note that the above about:blank dance is not necessary, it is just one possible approach.
The actual goal is to assign new containers on every navigation if so determined by the addon logic, which will need to inspect the tab's current state and the target URL to make that decision. And that assignment does not affect the past, only the navigated-to page. Therefore no rewriting would have to happen.

And since history has to record the context ID anyway I'm not quite sure why this is such a large hurdle.

[jonathanKingston]

I'm not quite sure why this is such a large hurdle.

Because the web has many features which makes this hard like window.opener this would also indeed break OAuth as previously mentioned. If you wanted opener to work across containers it is a privacy issue.

Well, to me automatic change-on-navigation and manually changing are more or less the same thing, at least as far as the underlying machinery needed is concerned.

If both of these allow back and forward to work yes they are the same. Again this is out of scope and we should be talking on the Bugzilla bug to discuss this being added to the platform.

The original bug here is about just doing exactly what Context Plus does and nothing to do with keeping the tab within the same window.

The window change requires a lot more security checking etc that will require additional work, I'm going to update the Bugzilla bug to explain this situation further. This indeed would help with the friction of assignment however it isn't as easy to implement as it seems and probably still a P5 that I can see.

I'm going to close this as I don't think we will ever be implementing this here users not wanting the privacy benefits can use Context Plus. Users wanting clean back and forward and cleaner assignment functionality can wait for the platform Bugzilla change.

/cc @groovecoder and @bakulf

[the8472]

Because the web has many features which makes this hard like window.opener this would also indeed break OAuth as previously mentioned. If you wanted opener to work across containers it is a privacy issue.

But I don't. OAuth is equivalent to privacy leakage. Of course I do not want it to work by default.

[jonathanKingston]

Yeah so if we sever opener between navigations this would break PayPal in this instance and other OAuth providers. That isn't an issue just something the extension author would need to know.

However yeah handling the opener state back and forward between navigations isn't super simple. Let's continue the conversation on Bugzilla thank you for updating there too!

[Stis]

@jonathanKingston
Tile Tabs like i love it right now with Multifox on FF52.0.2
Tile Tabs WE like i will never use it. The more I see from WE, the more i feel i'll stay far away from it... :(

And if I don't use Tile Tabs anymore, I don't need to avoid the "destroy and recreate" part of changing context. :]

[jonathanKingston]

@Stis ah ok, I think they are likely to allow the window of Firefox to be hidden more in future so I think that will become more like the old version over time.

[saboxerman]

Hello,

The most recent comments have left me with a little head spinning as I'm not well versed in these sort of issues.

Is there any speculation on the topic of this thread occurring?

Another thought I can at least work with is having tabs open up in a certain container as a default when I open my browser. Meaning, dictating one eBay tab to open normally, another to open in a Business container, and my third opening in a Shopping container. I could live with that.

[saboxerman]

Just dug a little further. Context Plus 100% resolves what I need tabs to do.

[jonathanKingston]

I created the wiki page which is perhaps clearer. Happy to answer questions to make it clearer though.

[neclimdul]

"Essentially you turn containers into a organisational tool rather than a privacy one. "

This is actually _exactly_ the opposite of the reason I want to move containers.

Lets follow the process:
1) Click a link in email.
2) "Oh, I'm not logged in to application X... right not the correct context. "

No there are two options
1) I copy the url, open a new tab in the container, paste the url and go, close the old tab. This just bypasses the privacy concern but it also makes me angry because I had to grab my mouse and do a bunch of stuff.
2) I log in. This not only bypasses the privacy, it messes up all the privacy on my hole un-associate container. Also, again I'm angry because containers didn't work for me.

In reality, just sending a URL to a container is the least destructive privacy option and people are going to do it anyway or not use containers so it could at least be easier and done in a way that the extension has the possibility of cleaning up tracking tokens and stuff.

[ArchangeGabriel]

So, I’ve finally found some time to read everything about this issue and I now see what the point is, but my opinion is that this is plainly wrong anyway.

The concern is about privacy leaking when reloading the URL into another container. But not allowing to reload an existing tab into a different container does not solves this, because instead people will just do as they do now, i.e. reloading tabs manually but with the same result regarding privacy! So unless you’re planning to educate users about it (which would by the way be a tad easier if you had a warning about this in the reloading tab in a different container UI), refusing this non-feature makes no sense to me.

So as far as privacy is concerned, I’ve come to realize that there is only one solution: every site is a container, which is a title I’ve seen in my GitHub notifications but have yet to read about. But anything else means you will end up at some point leaking privacy.

Now don’t get me wrong: I’m looking for privacy, not tab management. But it’s not until now and reading everything that I understood the privacy implications of my behaviour. And indeed I don’t want to reload a tab into a different container, at least not blindly (but I think no-one ever thought about blindly reloading, generally we always have good reasons to do so), but I didn’t know that before reading everything here. So that’s my point on educating users: in the current way of doing things, they are no warnings, just something that looks like a missing feature in this add-on.

[cj1985]

Has this issue ever been solved or has it been stonewalled by one or two powerful figures' obsession over privacy?

(I love it when those in control think that how _they_ trade-off privacy/safety and convenience is also how everyone in the world should do so. It's like if they prefer vanilla to chocolate, they think that everyone in the world should do so too. No, some of us are actually adults who are capable of deciding if we prefer chocolate to vanilla.)

The only reason I'm using Containers rather than MultiFox is that MultiFox was shut down. I'd much rather still be using MultiFox which was far better, especially because of this one single feature.

If you're obsessed over privacy, a very simple solution is to offer an additional option where Containers users can choose whether they want this feature. I don't know why this hasn't been done yet.

                                 - Just another annoyed user.

[jplatte]

@cj1985 This issue has been solved insofar as there being another addon that adds this feature if you want it: https://addons.mozilla.org/nn-no/firefox/addon/context-plus/

[cj1985]

@jplatte: Thanks, this Context Plus add-on you recommend is certainly an improvement over the status quo. However it still isn't as quick and convenient as MultiFox. Ideally, what I (and I believe many others) would like are these features (which were provided by MultiFox):

Feature A.
Step 1. Click once on Multi-Container button, list of profiles shows up.
Step 2. Click on desired profile, new tab opens with current URL but with selected profile.

(In contrast, the Context Plus add-on requires that I (i) right-click on the tab; (ii) move mouse cursor down to "Move to Context" and wait for further drop-down window to appear; (iii) then "Ctrl+Click" desired profile.)

Feature B. The ability to rapidly open the same URL across multiple profiles. With MultiFox I could just click the MultiFox button, then click-click-click-click across all my different profiles and open up multiple tabs with the same URL, but each with a different selected profile.

(In contrast, the Context Plus add-on closes the earlier drop-down windows and immediately brings me to the new tab once I click on one profile.)

Hopefully someone can modify this add-on to have the above features. (I have also added the above requests as a review to the Context Plus add-on download page.)

[jplatte]

@cj1985 I'm not an addon dev. I'd recommend pitching this to the developer(s) of Context Plus, probably via a GitHub issue (https://github.com/totallymike/contextPlus/issues).

[Karlheinzniebuhr]

+1

[maphew]

I created the wiki page which is perhaps clearer. Happy to answer questions to make it clearer though.

Thanks for the wiki page. It made this long twisting thread understandable. Maybe edit the OP to reference it.

My 2c: "Containers" is an unfortunate choice of word, "Profiles", "Personalities" or at least "Profile containers" would be better. Containers are bins I throw things in to manage them, like with like, cups with glasses, bowls with plates. That's what I want to do most often with my tabs, without concern for privacy, it's all me and they're all mine, in the same kitchen.

Profiles are when I want different personalities and strong divisions between, different kitchens, a.k.a privacy. Using a name that highlights the design purpose might help with the confusion and reduce the 'another annoyed user' occurrences.