Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defaulting to no container not possible after setting default container for website #2320

Closed
ghost opened this issue Mar 27, 2022 · 5 comments

Comments

@ghost
Copy link

ghost commented Mar 27, 2022

Once you set "always open in container xyz", you cannot go back. If you open a new tab and go to a site for which you set a default container, you're asked if you want to open it in the assigned container, or in "Container" (which means no container, lol, did someone test this shit?). If you choose (no) "Container" and check "remember decision", it's not remembered but instead you're asked again and again. You cannot go back to defaulting to no container.

@shtrom
Copy link

shtrom commented Mar 28, 2022

Somewhat related to #2314?

@achernyakevich-sc
Copy link

@samo296 It looks like your issue is just another duplicate of others that could be related to misunderstanding of the related MAC feature. :)

I would like to recommend to carefully read this comment that will bring understanding how it works.

Yes, current implementation of this feature is not good and I would ask you to check #2294 and vote for it. Maybe after collecting many likes MAC developers will detect it and implement. :)

As well if you just need to cancel your decision to open some site in some container then there are several solutions for it. Probably the simplest for you would be - click MAC button in Firefox toolbar, click Manage Containers at the bottom of panel, select container that the site configured to be open in by default, click Manage Site List.. and delete the site from the list by click to trash button. After that the site will be open in the container you try to open it in without switching to the assigned on.

At the end, as this issue looks as duplicate, could you close it and this will shows other that it is not a bug and comments point to valuable information. :)

And... more votes for #2294 - more chance that soon this feature will receive more reasonable interface.

@ghost
Copy link
Author

ghost commented Apr 5, 2022

@achernyakevich-sc I guess you're right. This dialog is basically a delayed "Are you sure?" after setting a default container, with a UI that is nearly impossible to decrypt. It is anticipating the pretty likely circumstance that someone confuses the almost identically looking button for the "Always open in" with the MAC extension button, erroneously setting a default container, only to offer no way to revert it... and on top of that it is even disguising itself as an option to do exactly that. It's actually kinda funny.

@achernyakevich-sc
Copy link

... It is anticipating the pretty likely circumstance that someone confuses the almost identically looking button for the "Always open in" with the MAC extension button, erroneously setting a default container, only to offer no way to revert it... and on top of that it is even disguising itself as an option to do exactly that. It's actually kinda funny.

If you have a problem to revert default assignment then it is other issue. And is not an issue because there are at least three ways to revert. See this comment for details.

@samo296 I think now you know why and how. :) So could you close this issue and people will see it is closed so aswers are inside and will read comments to get their issues cleaned.

@dannycolin
Copy link
Collaborator

You need to remove the assignment. See https://github.com/mozilla/multi-account-containers/wiki/Frequently-asked-questions#remove-always-open-in-site-from-a-container

There's also a feature request (#1442) to honor manually reopening a tab in the select (no) container. Closing in favor of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants