-
Notifications
You must be signed in to change notification settings - Fork 343
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
Feature Request: Provide a toggle button to disable "Open this site in your assigned container?" #2190
Comments
I had this same issue recently. It happens because you use the "Always Open this Site in..." option. The only way I could find to undo it is to remove the container and adding a new one. |
Yes, this really needs a 'never ask me again' option. And possibly the option to store the answer per domain rather than by URL (which is what I assume it is doing). And a way to see what data is stored related to this feature and clear it. For example, opening a Zoom meeting via URL is always unique, and so always asks, but I'd like to not be asked for any URL in the zoom.us domain. But I do want to be able to manually specify a container, so I can log in to several different zoom account web portals. |
This comment on another issue helped me in what I think is a similar situation. #2151 (comment) That is I accidentally requested google.com to open in a specific container, and everytime I googled something it asked whether I want to open in in that container. Removing google.com from the container in question by following the (unintuitive) linked procedure fixed this issue. |
Thanks—yes, that's fixed it for now. I also found the navigation in that panel (getting back from removing the site from a container) to be really temperamental, so I think there are a few rough edges on this extension... |
Would you be so kind to close this issue as it is resolved. :) |
That would be very useful feature for me too. Just use the 'active' container and never ever ask me again :) |
+1, same happened with me, it solved it. I think 2 alternate ways:
|
There seem to be several related issues both here and Temporary Containers that basically boil down to MAC needing to lose the single Always Open In per domain. There's any number of reasons to have multiple containers for a domain, and while you can get around it by disabling automation... why should you? Automate the heck out of it! Only prompt the user when you absolutely have to (and then please do, don't guess). Allowing per-URL configuration would solve some of the problems, and allowing storing multiple defaults with the UI supporting that e.g. with the dropdown and with navigation originating from each respecting the selection unless overridden would solve some others. |
Great!
I would propose to vote for the changes to the confirmation screen described in the #2294. To my mind it will seriously simplify understanding of MAC functionality. :) |
@effs This functionality is already implemented and available for Firefox users. But it is implemented in Containerise add-on that is greatly integrated with MAC. See #2271 (comment). |
@KevinSpringfield previous comment helps to resolve your use case. If so then it would be great to confirm it by closing this issue. :) |
@achernyakevich-sc Thanks for the pointer, I'll check it out! If I understand correctly, I can disable "always open in" in MAC and use Containerize for that part? I'll have to see how it integrates with TC. I'd still consider it to be better as part of the default feature set, same as temporary containers, as it would allow one clear place for the rules and a clearer way to escape an assignment (i.e. if I force-open an assigned domain in a non-assigned tab, any clicks from that tab should respect the setting). I know it's not a simple thing to get the feature set and interface right for that, but it's far less simple for users to get it right having to combine (and find!) multiple addons that may or may not interop exactly right - and I consider the ability for just your normal internet users to separate browsing spaces in the MAC/TC/Cz way to be essential going forward. Fully separate profiles is an outdated solution, but even my programmer circles could use a more straightforward alternative. |
Thanks guys, my problem has been solved. Issue closed. |
In my use case, I need to use multiple accounts such as admin coount, test account 1, test account 2, et cetera on the same site and this plugin used to meet my need before feature of "Open this site in your assigned container?" was added.
I prefer to choose which container on my own instead of always asking me which container to use.
It will be nice to have this feature, thanks :D.
The text was updated successfully, but these errors were encountered: