-
Notifications
You must be signed in to change notification settings - Fork 65
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
Does not open a temporary container for a new tab #633
Comments
I'm afraid I can confirm that this problem exists. My test is very simple. I started Firefox several times like this: The same test with https://google.de and https://wikipedia.de leads to different containers. Regards, Thiemo |
@Starwhooper Thanks for your confirmation. The extension has not been updated lately whereas Firefox has and maybe everything is related to changes in Firefox itself. I cannot tell whether this is the case but I hope the developer will. Maybe you could attach relevant logs so the developer will have more information. |
Its still very hard for me to inform you, but the developer very unfortunately isn't among us any more. 😢 |
@crssi Mind me asking a newbie question, how do you know that? |
It looks to me that this is also a new bug in Firefox's own container functionality too. If I have a tab open on This isn't how it should work in the basic container functionality, even without Temporary Containers, right? It should respect the "always open" setting for that domain, right? I have not yet tested this in a clean Firefox with no extensions installed. Also I haven't found any other information on this bug other than this issue.
We could work towards submitting this to bugzilla if it is a Firefox bug, and maybe get this fixed without changing Temporary Containers. |
Thank you for that info. You can easily verify whether the issues related to Firefox or Temporary Containers (or both) :) by:
We will be happy to hear from you |
I believe this commit is ultimately the cause of this behavior, and it was made because of this feature request so I don't know if it'd be treated as a bug, however the lack of a way to disable it seems like an oversight to me. Unfortunately it also seems to break this extension :\ |
@p5nbTgip0r Thanks for that. |
https://bugzilla.mozilla.org/show_bug.cgi?id=1874599 Looks like this might be worse than it seemed at first. The new guessing feature can even override your "Always Open In Container" settings. One downside here is that "Always Open" seems to be a feature of the official Multi-Account Containers extension, but since that extension is almost required to be able to use containers, I'd still consider that pretty bad. |
For the record: tested this now in Firefox 124 with My fear was that the fix would again bypass Temporary Containers and force all external urls into the default container ("no container"), but that did not happen. |
Actual behavior
I am using a new Firefox profile with only Temporary Containers installed (see support.txt and debug.log below), which is configured in Automatic Mode. I do not use a temporary container with any target domains. That is, even if I open the same domain, temporary containers used to open a new temporary container.
Today, I've noticed that this is not the case, if I head to the console and do (yes, I issue the same command twice)
Then Firefox will open the URL in the same container. The same holds when clicking a any link in external program, Firefox will open the URL in the same container of the domain.
I feels like it uses a Permanent Container.
Expected behavior
For every new tab, temporary container must not switch to a container with the same domain.
Steps to reproduce
Notes
This kinda the opposite than Multi-Account Containers since the URL is not opened in a new temporary container. It is opened in the same container which the user is already logged in.
I also noted that even if there are 2 different temporary containers for the same domain, the first temporary container will be used for a URL with the same domain.
Files are attached
debug.log
support.txt
The text was updated successfully, but these errors were encountered: