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:

[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 :(

[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.

[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!

[ghost]

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