Allow 'default' as a possible host name to specify the default contai…#20
Allow 'default' as a possible host name to specify the default contai…#20lisdude wants to merge 1 commit intokintesh:masterfrom
Conversation
…ner that external links open in.
|
+1 for this feature. I like to stuff services into their own container, but want anything not specified to fall back to a default container (that I can occasionally delete to remove cookies). |
|
The no container options already opens it in a default container. Am I missing something? |
|
I think you are missing something...but I'm not sure this PR fully addresses the issue. Firstly, what you are missing is this - I will use an example. What you are missing, is that *When there is no rule in Containerise, the current container is retained. It should go to the 'No Container'. I tried to work around this by making a rule of * , No Container. It is ignored. Whatever container I'm in, it stays in that container if there is no matching rule otherwise. Rules specifying * as the hostname are not used, if you are already in a container. So, it seems simple - allow links which do not match any rule, to open in the 'No container' container - However, this does not match some use cases, such as people who use containers to separate identities on the same website for example #53 What is needed here, is a different approach to the rule set for assigning containers. We need a ruleset for ENTERING a container, and another ruleset for EXITING a container. Intuitively, the way to do this is to have a list of containers, and for each of them, a list of URLs/masks/regexs (like we have now) which will cause the browser to switch to that container.... and then a set of the same style (masks/regexes) which should be applied to links followed from within that container. For ease of use, the 'No container' should be selected by default for any link not matching the entry rules (ie, respect the ' asterisk ' wildcard URL rule), and people who have the edge case of using multiple containers should use the exit ruleset to perform actions such as staying in the same container regardless of the link (again, respecting the '*' URL rule, and assigning it to the same container for which they are editing the exit rules. I'm very happy to contribute code for this, because TBH, without it, both this addon and the entire container feature of FF are useless (as mentioning in other comments - we containerise our identity and then it spreads outside of that website that is contained. Why bother?! Such an implementation (entry AND exit rulesets, both of which respect * as an 'anything not matching the other rules' rule, ) would resolve: And actually make FF's containers feature functionally useful. As I said, I will be very happy to contribute code here. I am a retired dev and time-rich and have the experience to do it and I'm motivated. I just need to work out the goals before I start cutting a PR that might be rejected. Let me know how you want me to go and I'll get to work. Edits: Typos and formatting |
|
|
Meanwhile I have a workaround which covers some use-cases: This works so long as I do not need to have a certain container remain within that container (eg the Google Work container example given above) |
|
@NomDeMorte thanks for this workaround! Still, this feature should be part of Containerise itself. |
|
Hey guys, question: If this PR would have been merged, do you think it could it close #10? |
|
The idea is nice, but imo it'd be better to add this to the UI using a dropdown-list. That would make it possible to add more options in the future e.g "random container" and make the feature immediately visible to users. |
|
@NomDeMorte, @lisdude Can you please checkout master and see how the recent change works. It will open any unmapped urls in firefox-default when visiting from withing a container. |
Sorry I'm too late, for some reason I don't get any notifications on github any more :( I came here in a panic when I got automatically updated. I think there may be a bug. When I open a link in a new tab, I get an empty tab in the origin container with the destination address in the URL bar, and then the same address is opened in another new tab in the appropriate container. I then need to close the empty, uncontainerised tab, manually. The good news is, that opening a link from a containerised tab, which has no matching rule, does open in no container. So that's nice :) |
|
I see you have rolled back, thanks for that.... But I hope you haven't given up on this, as it was nice to have links opening in the default container :) |
…ner that external links open in.