multi-account-containers icon indicating copy to clipboard operation
multi-account-containers copied to clipboard

Always Open Site In Container cannot be disabled once engaged

Open Bilge opened this issue 2 years ago • 26 comments

  • Multi-Account Containers Version: 8.0.4
  • Operating System + Version: Windows 10 20H2
  • Firefox Version: 95.0.2
  • Other installed Add-ons + Version + Enabled/Disabled-Status:

Actual behavior

Once a site has been opted into always opening within a designated container, it is no longer possible to select opening in no container, and consequently, you will always be prompted to open in the designated container.

Expected behavior

First, there should be a clear list of sites that have been selected to always open in specific containers, so that such rules can be edited and removed. Second, the interstitial screen should remember the decision to not open in a container when Remember my decision is selected (it does not, if you choose the left button).

image

To be clear, choosing Remember my decision should permanently dismiss the interstitial for the current site, but it does not, if the left-hand button is clicked along with it.

Steps to reproduce

  1. Go to any website
  2. Click Always open this in a Container button
  3. Pick any container
  4. Observe that opening additional links in new tabs for that site shows an interstitial screen prompting to open in the designated container

Notes

It is not possible to avoid the interstitial and go back to the default browser behaviour (opening new tabs in no container).

Bilge avatar Jan 12 '22 21:01 Bilge

It is very similar to just reported other issue - #2257.

Please, see my comment there.

If it will explain and resolve your issue then it would be good if you will close your issue because of duplicate,

achernyakevich-sc avatar Jan 13 '22 07:01 achernyakevich-sc

@achernyakevich-sc Not a duplicate, but I appreciate the information on how to remove the interstitial.

Bilge avatar Jan 13 '22 09:01 Bilge

I'm having this bug myself. Reading all the other bug reports, it seems part of the problem is a UI bug related to the text "Open in Container". But it seems like there's more going on than that with the setting not being sticky.

The suggested fix of using the right-click menu on the page to change the container preference does not work for me; there is no multi-account container entry at all in the menu.

This other suggested fix of opening about:devtools-toolbox?id=%40testpilot-containers&type=extension and editing Extension Storage to remove the key for the site in question did work for me.

NelsonMinar avatar Jan 16 '22 18:01 NelsonMinar

@NelsonMinar

The suggested fix of using the right-click menu on the page to change the container preference does not work for me; there is no multi-account container entry at all in the menu.

In reality comment provided two solutions. About right-click menu. Important is that page should be already open in the container. For regular pages open without any container this menu will not be available as it has no sense. Could you check?

As well could you check second solutions from that comment about opening MAC menu by click to MAC button on toolbar?

achernyakevich-sc avatar Jan 17 '22 06:01 achernyakevich-sc

I was able to do remove the container setting for a URL in the UI in this specific, confusing way:

  1. Use the dialog to open the link in the unwanted named multi-account container (MAC).
  2. In that new window, right click the MAC button in the URL bar to bring up a popup menu. Normally this menu just has "Manage Extension" and "Remove Extension", but in the contact of a named MAC it will also have menu items related to managing that named container.
  3. The menu item "Always Open in This Container" should be checked. Select it to deselect it.

Update: when the new tab in the MAC first opens, the right click menu does not contain "Always Open in this Container". You have to switch away from that tab and back to it for it to show up. That's definitely a UI bug.

It took me about 5 minutes fiddling to get this to work

Another bug: another way to get the MAC popup menu is to left-click the MAC button, then right click the name of a container; there will be a "Firefox Multi-Account Containers" submenu that also has "Always Open in This Container" in it. You can select that menu item and it will uncheck in the UI, but the setting doesn't seem to take. Links will still offer to open in a container and if you open the submenu again in a new container window it will be checked again.

NelsonMinar avatar Jan 22 '22 22:01 NelsonMinar

Just logged in to say thanks @NelsonMinar ! The last paragraph of your post worked for me.

  • Simply right click on the "Multi-Account Containers" extension in the menu toolbar
  • Tick and untick "Always Open in This Container" (should be the first menu element)
  • Done!

Yachont avatar Feb 04 '22 21:02 Yachont

I had the same issue! Thanks @NelsonMinar and @Yachont for your help, it worked!

Altonss avatar Mar 20 '22 20:03 Altonss

I updated my instructions with notes about a UI bug; you have to switch away from the tab and back to it for the menu item to show up.

I seem to keep triggering this undesired behavior about once a month. I finally figured out how I'm doing it; I'm used to opening a specific MAC by left-clicking the icon in the URL bar. I think that used to just open the link in a container, but now the title of that menu is "Always Open This Site In..." so I guess it sets a permanent preference.

The UI for all this is confusing. I hope someone can look at improving the design.

NelsonMinar avatar Mar 27 '22 15:03 NelsonMinar

UPDATED ON: 2022-12-21

@NelsonMinar It looks you have just found another way to disable Always Open Site in Container feature. :)

I will try to summarize that I know. There is at least three ways to do it.

Important Prerequisite for way 1 and way 2 - the site should be open in a container. If site is open without any container it will not work as mentioned menu items will not be available!!!

  1. right click on any place of the page to call context menu then selecting Firefox Multi-Accounts Containers menu item and ticking/unticking Always Open in This Container in sub-menu.
  2. right click on MAC button in URL bar (not in the Firefox toolbar) and ticking/unticking Always Open in This Container in the popup menu.
  3. click MAC button in the Firefox toolbar, click Manage Containers at the bottom of panel, select a 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 that will become visible when you will move mouse over site in the list.

I think more than enough ways to treat this issue as not a bug. And use this instruction for users who will report similar again and again. :)

Meantime, I completely agree that in some areas MAC UI has really completely misleading interface. So I would ask all who read this comment to check proposal of #2294 and vote for it. I think it will prevent reporting of new duplicates...

achernyakevich-sc avatar Apr 02 '22 09:04 achernyakevich-sc

About once a month I have to revisit this bug report to find my own notes about how to fix it. Someone really needs to revisit all the UI for URL/container assignments. It's too easy to accidentally assign a URL to always open in a container, it's confusing when you do it, and it's very difficult to undo that assignment.

FWIW in v104 Firefox has a new bug or confusing UI. The popup to open the URL in a container has "Open in Container" as a button; clicking that actually means "don't open in the assigned container but whatever container this tab currently is in" (in my case, the default or no container). That's confusing. But what's worse is if I check the "Remember my decision for this site" box and then click "Open in Container" it does not seem to actually remember anything; next time I open this URL it still gives me this choice dialog. I'd hoped it would cause Firefox to forget the URL assignment to a special container.

firefox_3NS8mAEQop

NelsonMinar avatar Sep 22 '22 18:09 NelsonMinar

@NelsonMinar see my previous comment that in details describe how to fix your problem and gives reference to the GitHub issue that being implemented will avoid misleading in UI (I will appreciate if you will vote for it).

@Bilge I would appreciate if you will have closed this issue so people will see it and will look to the comments that explain how they could avoid their problems. :)

achernyakevich-sc avatar Sep 27 '22 19:09 achernyakevich-sc

Important Prerequisite - the site should be open in a container. If site is open without any container it will not work as mentioned menu items will not be available!!!

This is a bad situation. It's certainly possible for a website to immediately redirect when it detects you're not logged in. The target of this redirection may be a different website (say, mail.google.com redirecting to account.google.com) that opens in a different container, breaking the entire login flow. It can be hard to go back to that original URL.

It would be so much better if the extension's preferences just would have a list of websites & their container pins, and make it possible to remove websites from that list.

sybrenstuvel avatar Dec 20 '22 11:12 sybrenstuvel

Important Prerequisite - the site should be open in a container. If site is open without any container it will not work as mentioned menu items will not be available!!!

This is a bad situation. It's certainly possible for a website to immediately redirect when it detects you're not logged in. The target of this redirection may be a different website (say, mail.google.com redirecting to account.google.com) that opens in a different container, breaking the entire login flow. It can be hard to go back to that original URL.

It would be so much better if the extension's preferences just would have a list of websites & their container pins, and make it possible to remove websites from that list.

@sybrenstuvel Sorry for misleading with that "Prerequisite" in my comment. About one year ago it incorrectly described as it is related to first two ways to solve problem only.

Option number 3 is exactly the way to resolve problem through MAC add-on preferences (accessible through) "Manage Container" button.

I will update that comment to make it more clear and straightforward.

achernyakevich-sc avatar Dec 21 '22 19:12 achernyakevich-sc

Regarding the comment above with the 3 methods for reverting a site back to the default container: I have tried method 3 dozens of times and it isn't working. I am trying methods 1 and 2 today. We will see what happens. I think there may be a bug.

To be more specific, The sites I remove from the "manage sites list" show back up on the list. Normally the next day or a few days later. I am also going to try leaving one site on the list. Maybe when I delete all entries the code won't write a blank value to the config storage and therefore never overwrites the config entries that I want to be blank.

Paul-Spagnola-Work avatar Jan 03 '23 14:01 Paul-Spagnola-Work

@Paul-Spagnola-Work Looks like it could be issue about container settings Sync. Have you sync turned on?

achernyakevich-sc avatar Jan 03 '23 14:01 achernyakevich-sc

Yes, I do have sync enabled.

Paul-Spagnola-Work avatar Jan 03 '23 14:01 Paul-Spagnola-Work

@Paul-Spagnola-Work I'm pretty sure that in this case sync is just leading to restoring site lists for your container. You could look suitable know bug issue in the filter below: https://github.com/mozilla/multi-account-containers/labels/Component%3A%20Sync

As a temporary solution or proving of the sync root hypothesis you would turn off FF synchronization and check how site list will behave after it.

achernyakevich-sc avatar Jan 03 '23 15:01 achernyakevich-sc

@Paul-Spagnola-Work I'll save you some time, it's bug #2110 for whatever reason Sync must think your local data is less recent then the data in your Firefox Sync account. This results in the data reappearing.

dannycolin avatar Jan 03 '23 15:01 dannycolin

yep, sync overwrote the list again since my last comment.

Paul-Spagnola-Work avatar Jan 03 '23 22:01 Paul-Spagnola-Work

My whole search experience got ruined and there is no way to stop asking when using the browser bar to open a query in google since it doesn't remember the setting wtf

image

0xFlo avatar Jan 13 '23 07:01 0xFlo

There is no option to open the site in NO container

0xFlo avatar Jan 13 '23 07:01 0xFlo

@0xFlo Currently, the only way is to remove the assignment (How to remove an assignment).

I understand your frustration but I'd like to remind everyone of our etiquette. More precisely, 2 and 4 apply to the last comments.

  1. No abusing people. Constant and intense critique is one of the reasons we build great products. It's harder to fall into group-think if there is always a healthy amount of dissent. We want to encourage vibrant debate inside of the Mozilla community, we want you to disagree with us, and we want you to effectively argue your case. However, we require that in the process, you criticize things, not people. Examples of things include: interfaces, algorithms, and schedules. Examples of people include: developers, designers, and users. Attacking or encouraging attacks on a person may result in you being banned from Bugzilla.
  2. No obligation. "Open Source" is not the same as "the developers must do my bidding." Everyone here wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, you should not act as if you expect someone to fix a bug by a particular date or release. Aggressive or repeated demands will not be received well and will almost certainly diminish the impact of and interest in your suggestions.
  3. No spam. Posting comment spam will lead to the suspension of your account.
  4. No pointless comments. Limit comments on a bug to information which will help with resolving it. Unless requested, additional "I see this too" or "It works for me" comments are unnecessary. Constructive conversations unrelated to the topic of the bug should go in the appropriate discussion forum.
  5. No private email. Do not send comments on bugs by private email to users; no one else can read them if you do that, and they'll be missed and/or ignored. If an attachment is too big for Bugzilla, add a comment giving the file size and contents and ask what to do.

dannycolin avatar Jan 13 '23 17:01 dannycolin

This new feature is annoying, can't use conveniently for localhost website where i need to open the site in different containers. Pl. restore the feature as previous, where one can open the same site in different container. Esp. the UI is misleading and annoying

bhadreshmewada avatar May 01 '23 18:05 bhadreshmewada

This new feature is annoying, can't use conveniently for localhost website where i need to open the site in different containers.

@bhadreshmewada It is not a new feature but looks like configuration changes that you accidentally made for MAC Add-On.

According to your screenshot the most probably you have added www.google.com to the site list of Personal container. So every time when you try access Google it try to open it in Personal container and ask to confirm it. If it was your intention to do this then tick Remember my decision for this site and click Open in Personal Container button - next time it will not ask anymore and just will open it in Personal container directly. If it was not then you need to manage Personal container and remove www.google.com from the always open in Sites list....

More information you could find in my previous comment in this thread.

achernyakevich-sc avatar May 04 '23 08:05 achernyakevich-sc

It's pathetic that even though this issue has been open for over a year, nothing has been done to actually fix it.

MichaelNZ85 avatar May 19 '23 11:05 MichaelNZ85

I ran into the same issue and following FAQ, I am able to remove the individual site assignment to a container.

Firefox Multi-Account Containers version: 8.1.2 Firefox Browser version: 116.0.3

With thanks for the link in https://github.com/mozilla/multi-account-containers/issues/2263#issuecomment-1382174052 from @dannycolin

I would consider this issue resolved, in my opinion. Thanks.

aminmkhan avatar Aug 19 '23 11:08 aminmkhan