As already explained bug 1191418 comment 10 I would like to write an addon that automatically isolates pages based on rules and the top level URL so that minimal user interaction is required. I thought user contexts would provide this ability, but [:kmag] said in bug 1302697 that this is currently not part of the usercontext design. I think first party isolation (bug 1260931) clearly shows that there is a need to partition cookie jars along different axis than just the current tab. But in my opinion first-party isolation is too rigid and containers as exposed through the firefox UI are too coarse and too inconvenient to use. So my goal is to assign new containers on the fly based on various rules during tab navigation. This might also aide bug 1318652 since the work/external distinction does not seem to be associated with the lifetime of tabs but with URLs. Note that this feature does not have to be exposed through the default FF Container UI, I just want to do it via addon APIs.

moving discussion here from bug 1302697 since it seems more appropriate (In reply to Kris Maglione [:kmag] from bug 1302697 comment #40) > (In reply to The 8472 from comment #38) > > That design decision turned out to be wrong. > > Just because you don't like something, that doesn't make it wrong. > > There are a lot of reasons this restriction is in place. Leaving aside the > subjective and user experience reasons, it's necessary for technical and > security reasons that the origin attributes of a docshell never change. That doesn't seem to be true. The originAttributes.firstPartyDomain changes during top level navigation when that pref is enabled. Which is mostly what I want but falls short in some aspects. > The amount of complexity that that would add means that there would have to > be > a *very* good reason to do it, and I'm not convinced that there is. Well, my motivation is multifold. For sites on which I am an anonymous read-only consumer I generally want to turn off cookies and related stateful features. Alas, this breaks ways too many sites these days. Redirect loops, forced interstitials or JS exploding on localstorage. So to work around that I want to use user contexts as automatic private browsing sessions that regularly get discarded to approximate stateless behavior. But besides read-only pages there are also sites where I do have accounts, where I write things. At least when opening them through the URL bar I don't them to end up in a disposable session and want them to have my login. I want this to happen automatically because opening something in the "wrong" tab and not being logged in is a nuisance that discourages using privacy features. Yet another concern is of course the inclusion of content in 3rd party sites. E.g. embedded youtube videos when I have a youtube account. An example where first party isolation does not work as desired is the stack exchange network where a common login silo is hosted under different domains. Conversely, I may have a google account, but I don't want to use it for regular google searches, so just going to google.com should not automatically use the google container while going through mail.google.com should. Those are just my personal preferences. But when taken together they meaan I want to decide which site gets to see which cookie jar based on a set of programmable rules and not based on the rigid tab-container or firstPartyDomain approaches.

Tanvi, would you know if this fits into the containers/contextual identity roadmap?

I also want this feature. Here are two usecases: 1. I get a lot of links sent to me via email/irc/etc and when I click on them they open in a normal tab. Often these links are to something where I need to be logged in (e.g. github) so I get a login or 404 page, have to copy the URL, open a new container tab, and then paste the link. This is a terrible workflow. 2. I'm on a site and then realize it wants to let me log in via some service where I'm logged in in a different container. This happened right now when I wanted to log into bugzilla via github. I again had to copy my location, open a new container, paste, then login. Also awful. It is, without a doubt, going to be necessary to allow users to move tabs between containers if this feature is to gain any traction. There are simply too many cases where I want to switch and maintain context. I'm not sure if this is the right bug for this, I can move it or open a new one if not. Thanks!

I feel the need to lend my voice to this issue as well. I just learned about containers and immediately enabled it on my browser. After opening a tab in a container, my first instinct was to organize my remaining open tabs into the appropriate container. My use case is similar to Nick, I end up opening a lot of links as a result of a click. I am a tab-a-holic and view the primary benefit of Containers as organization, etc. While the security/privacy/isolation features are nice, they are secondary to being able to manage tabs and the associated memory consumed by FF. I love the idea of being able to snooze certain sets of tabs while I'm not focused on the activity that caused me to open them (I have tried a couple of extensions to help with that but never found one that I liked). So... in short.... please please please consider at least providing a feature to migrate a set of URLs from a set of open tabs (leaving all of the cookies and user data behind). It would greatly improve the utility of this feature in my mind.

I would like to put in my voice to this issue as well. I definitely visit webpages more often by following links, than by opening a tab and entering a URL. I end up having some tabs that are in a container, and closely related tabs unclassified, which actually makes it harder to navigate through. I also heavily support OP's suggestion of using rules to automatically classify tabs. I used to have a personal extension that did that for me based on regex's, and would love it if Containers did as well. With these two features, I think Containers could be the best method of tab organization I've used (even better than Tab Groups, which I was a fan of)

Cross references: Consider a tab context menu option to convert a normal tab to a container · Issue #311 · mozilla/testpilot-containers <https://github.com/mozilla/testpilot-containers/issues/311> (2017-03-02) Move tab from container or to container - Containers - Mozilla Discourse <https://discourse.mozilla-community.org/t/-/14134> (2017-03-03) Embrace the use of containers for tab management · Issue #336 · mozilla/testpilot-containers <https://github.com/mozilla/testpilot-containers/issues/336> (2017-03-04)

… Can't add Open Tab to a Container · Issue #317 · mozilla/testpilot-containers <https://github.com/mozilla/testpilot-containers/issues/317>

Changing this priority to P5 the reality that we have not considered this much internally. There are some ideas on how to implement a "First move" to containers if all default tabs are isolated when containers are enabled. This requires a huge amount of work and certainly isn't a priority. It also doesn't fix users who want to move: Personal -> Work or move more than once. In reality I think this should be WONTFIX as this is tab management and not containerisation. The only solutions that seem acceptable are the ones that keep users safe from trackers, these however are a LOT of work. Answering Keelers question, I don't think this will be on our roadmap at all this year.

Since there seems to be some confusing on the testpilot issue tracker, I'll try to clarify my request here. I'm *not* asking for the ability to change the context ID for the tab's current state. I.e. the current page and current history entry should always remain in its current context. What I want is to set the ID so that next navigation within that tab will move that new page to a different container. A tab's history could look like this: DOMAIN | CONTEXT ID foo.com | 0 foo.com | 0 bar.com | 1 bar.com | 2 bar.com | 3 baz.com | 3 foo.com | 0 The addon would intervene via page navigation events - ideally via onbeforerequest since it provides more information than onbeforenavigate - and decide which ID should be used when the navigation completes. Back-bavigation would also go back to the previous container associated with that history state.

As discussed on Github: https://github.com/mozilla/testpilot-containers/issues/311 This bug is actually about allowing a Tab to transition from one context to another on navigation. This isn't about converting the current URL from one context to another. Instead this is more about changing a tab to a new userContextId and keeping back and forward functionality. This would be useful for the test pilot assignment feature being cleaner in UX. However due to opener severing I don't think this is an easy task. :baku you have worked on these style features is this something that we should be considering?

Styling is not a super complex issue. What I'm thinking is the docShell part: We need to support bfcache, reloading and a lot of details at a platform level. Probably it's better to switch docShells when OriginAttributes dictionary changes. A similar setup exists for pre-rendering. We need to talk with some docShell peer. Can we organize a meeting in SFO?

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

I would just like to add my support for nick and Dulani's suggestion. And it seems to be something people are really looking for. Containers do give a nice way to organize things, as well as add the security benefits. But if you're clicking new tabs and opening links then it makes it difficult to do the workflow. I am totally fine with being logged out when switching a tab to a container but I totally see many use cases where I want to either put a uncontained tab into a container or move the container that a tab is currently in. Copy pasting that tab is extremely cumbersome as compared to Right Click > Move To Container. I fully believe that this will highly encourage the use of containers. Again, this is completely fine if it logs you out of current accounts associated with that tab. I just think that the copy paste part should happen in the background and making this workflow feel effortless would highly encourage the use and adoption of containers.

Special attention please to <https://bugzilla.mozilla.org/show_bug.cgi?id=1323873#c10> above (2017-06-06) for guidance on what is, and is not, within the scope of this bug 1323873. ---- Below, a few things that may help to understand what's beyond the scope of this bug. Under _Security/Contextual Identity Project/Containers - MozillaWiki_: What is (and isn't) separated between Containers <https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#What_is_.28and_isn.27t.29_separated_between_Containers> So with Firefox containers (usable without any extension), and with Mozilla's extension <https://addons.mozilla.org/addon/multi-account-containers/>, there are emphases on: - containment without movement. Recommended reading: - <https://discourse.mozilla.org/t/-/14134> and <https://discourse.mozilla.org/t/-/18931> (I have requested a merger of the two) - An Update on Firefox Containers | Tanvi Vyas <https://blog.mozilla.org/tanvi/2017/10/03/update-firefox-containers/> - Privacy best practices <https://hacks.mozilla.org/2017/10/containers-for-add-on-developers/#publishing-your-extension> under _An overview of Containers for add-on developers ★ Mozilla Hacks – the Web developer blog_

Being able to convert existing tabs to tab containers would be nice, at least as a context action if nothing else. I used a addon to add tab groups until it was disabled due to being a legacy extension, and now I have quite a few tabs that need to be moved over to the new system

I hope the summary is less prone to misinterpretation now.

Yes, that seems more reasonable. We should be able to treat it like a process change.