Temporary-containers: Adding new sites to Multi-Account Containers requires disabling of TC

[xarx00]

• Temporary Containers Version: 0.90
• Multi-Account Containers: 6.0.0
• Firefox Version: 60.1.0 ESR x64
• Operating System + Version: Windows 7 Pro x64
• Non-default Options/Preferences in Temporary Containers:
  General > Automatic Mode = off
  Isolation > Multi-account container = Enabled
• Settings in
• Other installed Add-ons + Version:

Purpose of the settings above is to isolate explicitly specified domains (in Multi-AccountContainers, futher M.A.C) to their containers, but whenever I click a link to another domain, the site opens in its own container (perhaps a tmp container). The M.A.C alone don't allow this, hence I use it together with TC. It works - to an extent - fine.

Problem: When I want to assign a new domain to a container in M.A.C, I am not able to do that without disabling TC first, TC doesn't allow me to do that.

Steps to reproduce

1. Open a new tab with File > New Container Tab
2. In this container tab, type http://www.somedomain.com to the address bar
   Then I plan to add this domain to M.A.C

Actual behavior

TC changes the selected container to a tmp container for the new domain, because the domain is not yet assigned to a container in M.A.C.
I have to disable TC and repeat the process with TC off. After adding the domain, I have to enable TC again.

Expected behavior

TC leaves the manually typed URL in the selected container. Then

1. I can click the M.A.C toolbar icon > Always Open In Container

[xarx00]

Some dirty solutions are mentioned in https://github.com/mozilla/multi-account-containers/issues/976#issuecomment-353465931 and in https://github.com/mozilla/multi-account-containers/issues/976#issuecomment-353456748.

[hackel]

This is a frustration indeed. As an example, I opened a link to github.com, it opened in a new temporary container. I converted that to a permanent container through the toolbar icon. I told MAC to always open github.com links in that container. Everything there is working great.

Now I want to add gist.github.com to this container. By default, it opens in a new temporary container (tab1). If I right-click on the tab and choose "Reopen in container > github.com", then that gets intercepted and a new temporary container gets created (tab2). I have to first go into the Temporary Tab preferences and disable "Open new Temporary Containers if a Permanent Container Tab tries to load a Domain that isn't assigned to "Always open in" that container". Then open the gist URL in the github.com container, tell MAC to always use that container, and finally re-enable the setting in Temporary Containers preferences. This is quite a long, convoluted process.

If anyone knows of an easier way, please let me know!

[zswanson]

I've also been having this issue and super frustrated with it, and after tinkering with all the settings today I found that this one seems to be the culprit.

Isolation > Multi-account container = Enabled

Once I disabled that, I can actually use the Multi-Account Container extensions "Reopen in Container" tab action to convert the tmp container to a permanent one, and then record that as a permanent setting in the MAC extension. No disabling of TemporaryContainers necessary, and I even have automatic mode turned on.

I think the underlying issue here is that a number of settings in Temporary Containers are not fully understood (and not documented well enough) and potentially conflict with one another.

[fancypantalons]

Echoing zwanson's last comment, for me, the root bug that would be great to see fixed would be to correct the behaviour with the Multi-Account Container "Reopen in Container" feature.

Right now, when you select a container, Temporary Containers takes over and flips back into a temporary container instead of allowing the switch into the target container.

My typical workflow for adding a site to a container is to open the site, "Reopen in Container", pick the desired container, then select "Always open in " in the Multi-Account Container dropdown.

But because Temporary Containers interruptions the process and forces the tab back into a temporary container, this workflow is busted.

The workaround, as zwanson indicates, is to disable the "Multi-account container" setting, but I really want that on! Otherwise sites like Feedly will always open links in the current (logged in) container, which is precisely what I don't want!

If this one bug is fixed, from my perspective, this add-on combined with Multi-account Containers is a virtually perfect combination! Really great work!

[crssi]

I have ditched MAC and Containerise due to problems. I have adapted differently.

See https://github.com/stoically/temporary-containers/issues/140#issuecomment-445251189

Maybe you will find it useful.
Cheers

[zswanson]

@fancypantalons

"The workaround, as zwanson indicates, is to disable the "Multi-account container" setting, but I really want that on! Otherwise sites like Feedly will always open links in the current (logged in) container, which is precisely what I don't want!"

No, that's kit correct. As I described, disabling that one option gives me exactly the behavior you're looking for. All clicks on links that go to a different domain open in tmp containers, but I'm now able to designate a tmp container to reopen correctly as a permanent one.

[fancypantalons]

@fancypantalons

"The workaround, as zwanson indicates, is to disable the "Multi-account container" setting, but I really want that on! Otherwise sites like Feedly will always open links in the current (logged in) container, which is precisely what I don't want!"

No, that's kit correct. As I described, disabling that one option gives me exactly the behavior you're looking for. All clicks on links that go to a different domain open in tmp containers, but I'm now able to designate a tmp container to reopen correctly as a permanent one.

Agreed, in general that's true.

Unfortunately, Temporary Containers appears to have a separate, unrelated bug specifically related to Feedly.

Go figure. :)

When using Feedly (which is in my Google container) with Temporary Containers and Multi-Account Containers, if you have an article highlighted and press "V" to open the article, it opens in the same (Google) container as Feedly, instead of opening in a new, temporary container.

Enabling "Multi-Account Containers" support in Temporary Containers resolves this, but unfortunately that feature triggers this bug where Temporary Containers prevents Multi-Account Containers from reopening tabs in a different container.

As a result, I either permanently disable "Multi-Account Container" support in Temporary containers and have Feedly open tabs in the same container as all my Google cookies (bad), or I temporarily disable "Multi-Account Container" support in Temporary Containers any time I want to reassign a site to a container, after which I turn the feature back on (less bad).

Truly, it is a rich tapestry. :)

[watsonarw]

I've run into this issue too. There's a few different use cases that are impacted by the same problem:

1) Trying to add a site to a permanent container - unable to open the site in the container in order to tick "Always open in"

A workaround for this is to temporarily disable Multi-Account Containers Isolation, open the site in the container, and tick it, then re-enable it.

2) A site that you want to open in multiple containers depending on context.
e.g. I have multiple email accounts (work & personal) with the same email provider (gmail). I use a container for each to keep them isolated, but not have to log in each time.

The same workaround as 1) can be applied for 2). However, I'm opening email/google services far more often than I'm assigning a a site to a container, so it's _much_ more annoying to do. As a result, I leave Multi-Account Containers Isolation disabled, even though I would like to use it.

A possible solution I can think of would be:
Add an option for Multi-Account Containers Isolation for Enabled except when coming from "Reopen in container" [or New Tab page].

Thoughts?

[stoically]

@xarx00
It would be nice to have a way to directly modify the MAC "Always open in" domains externally from other Add-ons like TC. That would allow to implement the feature assigning the current Tab URL to a MAC container. There's an open PR for that: https://github.com/mozilla/multi-account-containers/pull/1197

@fancypantalons

The workaround, as zwanson indicates, is to disable the "Multi-account container" setting, but I really want that on! Otherwise sites like Feedly will always open links in the current (logged in) container, which is precisely what I don't want!

The alternative would be to enable Isolation, either Per Domain with pattern e.g. *.feedly.com and set Navigating in Tabs should open new Temporary Containers to e.g. If the Navigation Target Domain does not match the active Tabs Domain (Subdomains won't get isolated). This would open third-party domains on feedly.com in a new TC Tab. Or you could configure the same in the Global Isolation.

@watsonarw

Add an option for Multi-Account Containers Isolation for Enabled except when coming from "Reopen in container" [or New Tab page].

Unfortunately I don't see a way of doing that because the "Reopen"-feature is natively implemented in Firefox and Add-ons don't have a way of detecting that a Tab was opened by this feature.

[fancypantalons]

Hmm, it seems that doesn't work.

I have no idea how Feedly opens links, but even with Feedly-specific isolation enabled as you suggest (I actually tested configuring those isolation settings to "Always" across the board), when you use the 'v' hotkey to open a link in a new tab, it opens in the permanent container used for Feedly instead of a new temporary container.

Enabling "Multi-Account Containers" isolation resolves this issue (the tab Feedly opens is opened in a temporary container), but then exhibits the other issue already described.

At this point, the simplest workaround for me would be to have a toolbar icon I could click to quickly disable and then re-enable the add-on. It's annoying, but less annoying than opening the add-ons panel each time! :)

[stoically]

@fancypantalons It should work since the MAC Isolation basically works the same way as the "normal" Isolation. Maybe feedly is operating on the domain instead of a subdomain, in this case the Domain Pattern needed would be just feedly.com. If that still doesn't work I'd appreciate a new issue including a debug log.

A fast way to (temporarily) disable Isolation is definitely needed. Some thoughts around that are also in #182

[AeliusSaionji]

Related - this may not be seen as an issue, but in order to escape this bug I've bumped into the following potentially undesirable behavior:

1. Rename current container from tmp# to say, Github, and check "Always open tab in this container".
2. After some time, Temporary Containers will delete the container Github as per the "Delete no longer needed temporary containers" setting.

Should Temporary Containers stop treating a container as temporary if it has been renamed?

[smichel17]

@stoically Can you detect the difference between these two scenarios?

1. This current page is open in my GitHub container. I click this link to example.com. I have MAC isolation enabled, so example.com gets opened in a tmp container (intended behavior).
2. I open a new, blank tab (about:newtab) in the GitHub container. I type example.com in the address bar and hit enter. I have MAC isolation enabled, so example.com gets opened in a tmp container (likely unintended behavior).

Rephrased, does the MAC isolation implementation know anything about the site you're navigating from, or only the site you're navigating to?

• If you can detect navigation from about:newtab, I propose that MAC isolation should not affect these cases. If there's really anyone out there who even wants MAC isolation to work in this case, it could be a 3rd option in the setting to use the current behavior).
  
  
  
  • This enables people to manually "reopen in X container" by copying the url, opening a new container tab, pasting, and hitting enter.
  
  
  • If you can't detect it directly, you might be able to hack in a workaround by keeping track of the address in the focused tab at all times, and checking against this. I could imagine this being buggy, though.
  
  
• If you can't detect navigation from about:newtab, I propose a workaround: When MAC Isolation is enabled, add an entry to the tab right click menu, "Force reopen in container", that will bypass the isolation setting.
  
  
  
  • This allows people to open the site, force reopen it in the container of their choice, and then save it to "always open in".
  
  
  • It's an awkward workaround for sure, since there would be two "reopen in container" entries in the tab right click menu (MAC's entry and ours).
  
  

[stoically]

@AeliusSaionji You can use the popup (activate in the advanced preferences), click the menu button top-left, then "actions" and "convert to permanent container". I'm personally not a fan of making it an implicit behavior. However, that won't work with MAC isolation enabled, since converting reloads the tab (to make the container name change visible) and isolation would reopen in a TC because the domain isn't assigned (same would apply for renaming).

@smichel17 If example.com is assigned with MAC to GitHub, then navigating from about:newtab should not open a new TC with MAC isolation enabled. And indeed, I've just tested it, and for me it doesn't open a new TC. If you can reproduce that on your end, that'd be a candidate for a new issue, preferably with a debug log. Thanks!

[smichel17]

example.com is not assigned with MAC to GitHub or any other container (github.com is assigned to GitHub). If I long-press on the + button and open a new, blank tab in the GitHub container, then navigate to example.com, it re-opens example.com in a temp container. Intended (proposed to change) or bug?

[stoically]

That's currently expected behavior. MAC isolation should really only allow assigned domains to open in a container.

To actually answer your question (I didn't realize that you posted in this issue for a reason, my bad): afaik it's not clearly detectable that you navigated from an about:newtab. The absence of originUrl in the onBeforeRequest details could be a pointer, but it's also absent if you already have a website loaded in a tab and then navigate to another website using the address bar or e.g. use bookmarks.

Manually keeping track of about:newtabs might actually work for that scenario - though, not if you have about:blank configured for new tabs, since clicking links that open in a new tab load about:blank first and those should always be candidates for isolation.

But, it should only allow loading the exact domain entered into the address bar to "overwrite" the isolation, which would make redirects (like the common domain.tld -> www.domain.tld) not work as expected. It also would "overwrite" navigation if you open a new container tab and click a website on the new tab page (I heard some people actually have activity stream enabled) or e.g. open a bookmark. So, all in all, I'd prefer to not implement that.

However, I like the idea of having a "Force reopen" button (that'd be still problematic for redirects, but those should arguably not happen in this case). I'll look to add that to the popup > actions section - and maybe in second step also to the context menu (probably when adding #185, which then would result in a Temporary Containers context menu entry, with force reopen being a sub menu). Thanks for the suggestion!

[curiosity-seeker]

Problem: When I want to assign a new domain to a container in M.A.C, I am not able to do that without disabling TC first, TC doesn't allow me to do that.

I cannot confirm this. For me the following procedure works flawlessly:

1. Open M.A.C and open the desired container by clicking it.
2. After the respective tab opens, load the desired website in it.
3. Right-click that site and in "Firefox Multi-Account Containers" check "Always Open in This Container".
4. Close the tab and open the respective website again: Firefox will ask you once more to confirm that it should be opened in the container it was assigned to in step 3.

Again, this works without any problems for me.

[stoically]

@curiosity-seeker I assume you don't have Isolation > Multi-account container = Enabled, but Disabled - in this case assigning is not a problem, correct.

[curiosity-seeker]

@stoically : Yes, confirmed!

[stoically]

v1.0beta4 has a circle icon button in the popup top nav, which allows to disable / enable Isolation globally - so adding new sites to MAC is possible by clicking that button, assigning, and clicking the button again. Just a workaround, but way more convenient than opening the full preferences page.

[stoically]

Putting this issue on the Blocked by third-party board. Will reopen if MAC implements the required API.