Stop asking for confirmation to always open in container

[MauroMombelli]

• Multi-Account Containers Version: 6.2.5
• Operating System + Version: Linux 5.7.0
• Firefox Version: 76

Actual behavior

When I set one website to "always open in container", when i try to open it it will ask again

Expected behavior

just directly open the page

Steps to reproduce

1. open Container tab (lets call it X)
2. navigate to a website
3. from the Multi-Account container menu, check "Always open in container X"
4. close the tab
5. open a new normal tab without container
6. try to navigate to the website
7. a page will appear asking again if you want to always open the page in container X....

Notes

point 7. should not happen, I already told to do so in point 3.

[B00ze64]

There's a reason for that 2nd question: What if you want to open that website in the CURRENT container, i.e. you already have the website opened in its assigned container, but you need to do another login, so you've opened a different container and now you browse to that website. I think it's annoying too, to have to confirm every container assignment I make, but I think if this was removed a lot of people might complain...

[MauroMombelli]

this happen also if I dont use any container and open directly a to the website, so then the question is, what "always open in container" actually does?

I also I this problem of double account, and so far my solution is to NOT use "always open in container" but manually select the container I want.
If you try mixing different container with the same website and "always open in container" you will find out the experience is quite confusing, sometimes you will be prompted on what container to use, sometimes not.

For example, if I am in the default container A with "always open in container", right click and select "open with container B" , it will ask me if i want to open with B or continue with A, something i explicitly requested.

Also for the same reason, if i selected "always open in container" in the menu AND also set it in the page (do we even have a way to differentiate between those two assignment? i how am supposed to explain this to people?) and then i EXPLICITLY request to open in a different container, it should open in the requested container.
But just because i explicitly requested it, there is no need to double guess: i dont see why it should try to correct an explicit command.
This is helpful for example to let a friend log once with their account without having to disrupt my workflow.

About people complaining, you cant make everybody happy, the best UX should win, and if it is that better, transition is not a huge deal

[michft-v]

+1 Yep this is making me look how to downgrade. (or possibly fork)

[samoylenkodmitry]

Actually, this transition hugely disrupts my flow. Can be made an option to "force always open in ..."?

[gluax]

Is there any update on this issue? I'm tired getting prompted for every link I open, even after I say open this link in this container it still prompts :\

[achernyakevich-sc]

@gluax I have not seen this issue earlier. But it looks as duplicate of many other. The main problem to my mind that it is not explained anywhere the how this functionality works. So when I see something like this I try to point that this is a duplicate, explain how it functioning and ask to vote for the GitHub issue that could resolve misleading.

So lets start from why. Currently user can define that URL that belong to some domain (not URL itself) should be always open in the dedicated container. As soon as user have it done any new attempts to open pages for the selected domain should be open in the dedicated container. But as user could accidentally set "Always open in container" and do not know how to rollback this setting developers of MAC add-on decided to introduce special screen where user should confirm his decision - user could do it by marking Remember my decision for this site checkbox and click Open in <ContainerName> Container. If it will be done this way then next time user will not see this screen anymore.

But if user didn't tick checkbox or clicked Open in Container (instead of doing as described above) then confirmation will not be recorded and next time user will see this screen again. As far as I know some user even use it as a features.

So this works as work. And there is not bug but there is different functionality than user could expect.

I think having this explanation current issue could be closed as in reality is not a bug. But I would propose not only close this one but as well to vote for the #2294 issue that propose some enhancement to the confirmation screen that will make it more clear and straightforward. :)

[gluax]

Oh interesting, for me it doesn't matter whether I check the box or not and click the same response everytime I still get prompted everytime :c

[achernyakevich-sc]

@gluax I would ask you to perform clean testing as I described.

As well you need to be sure that you have other containers management add-ons turned off.

BTW: Your case probably would be resolved by using of Containerise add-on (see #2271 (comment)). It provide possibility to set container per URL not domain.

[gluax]

Sorry, I don't see any instructions for clean testing? I re-read through your comment and your original linked issue.

Containerise unfortunately doesn't work for me. I need to be logged into different accounts for different organizations and seems adding the rules:

No container: github.com
Work: github.com/org
Doesn't seem to work with it.

EDIT: it seems uninstalling and reinstalling the extension has fixed the issue and that screen is no longer displayed though.

[achernyakevich-sc]

Containerise unfortunately doesn't work for me. I need to be logged into different accounts for different organizations and seems adding the rules:

No container: github.com Work: github.com/org Doesn't seem to work with it.

To my mind Containerise add-on could really help. You could define match patterns that will include Organization Name:

• whole matching github.com/OrganizationA - to be open in the container A
• whole matching github.com/OrganizationB - to be open in the container B

So if you will work with repositories of OrganizationA then it will automatically switch to the container A. For OrganizationB - to the container B. But if it is not related to any of these organization then it will be open in the container that tab was open initially (default or whatever).

EDIT: it seems uninstalling and reinstalling the extension has fixed the issue and that screen is no longer displayed though.

Then maybe it was a problem of some data migration during updating to newer version that could cause data corruption. But as soon as problem resolved then just we could recommend the same. :)

[dannycolin]

Duplicate of #796