Default containers

[ghost]

dev TODO

• toggable preference group
  Visuable toggle could be done with checkbox and CSS that hides, greys out or deactivates everything in the group
• create "container name" preference
• use "container name" preference
• Allow "No Container" as container name
• use "container name" preference with variables
• use "container name" preference with ms variable
• "rule" preference
• use "rule" preference
• use "rule" preference with variables
• create "lifetime" preference (ChoicePreference with radio buttons)
• use "lifetime" preference: "Forever"
• use "lifetime" preference: "Until last tab is closed"
• check containers at extension startup for lifetime preference
  Those that should've been deleted, will be deleted
• Grey out preference group when not selected

TODO future PRs

• Preference group presets

Discussion questions:

• How should preferences be documented without cluttering preference UI?
  • Wiki?
  • written in Markdown, converted to HTML and opened in an extension page.

---

This will contain the work on default containers as well as their preferences.

It will introduce the options for default containers described in #10 and #80 (possibly other related issues if I remember/find them again).

What is this "default container" you speak of

The container into which tabs will be placed that cannot be placed into any other container. In other words, if a tab opens or updates its URL to one that cannot be matched by a rule in the extension, it will be put into a default container according to the preferences listed below.

Preferences

Since there have been multiple proposals on what should be done with the default container and they are at times mutually exclusive, it will be up to the user to decide. In order to do so a group of preferences related to the default container will be provided that hopefully cover the requests.

The preference group will have certain presets for the user to reach certain configuration states easily.

Suggested preference group

The title of the group, as seen by the user, will be Default container. The entire group can be toggled on or off. If off, nothing will be done with unmatched URLs. Once activated the following preferences will come into effect:

Container name (string input)

The name the default container will possess. It will be possible to create a dynamic name using certain variables:

• ms: current time in milliseconds
• domain: the simple domain without the TLD or anything else
• fqdn: FQDN
  host will work as an alias
• tld: TLD

Other variables can be requested (most likely in feature requests).

Examples:

URL	containerise_{ms}	{domain}	{fqdn}	default container
https://example.com	containerise_1567718601836	example	example.com	default container
https://old.example.com	containerise_1567718628706	example	old.example.com	default container
https://an.old.example.com	containerise_1567718738989	example	an.old.example.com	default container

Lifetime (choice list)

• Forever: self-explanatory
• Until last tab is closed: Once the last tab in the container is closed, the container will be deleted too

A possible countdown e.g "60 minutes" might be possible, but that's out of the scope of this PR.

Rule addition (string input)

This will create an a rule for the container. This is specifically for #80. Containers could thus be automatically created for domains.

Available variables:

• domain: the simple domain without the TLD or anything else
• fqdn: FQDN
• tld: TLD

Examples:

URL	.{domain}.	*.{domain}.{tld}	{fqdn}
https://example.com	*.example.*	*.example.com	example.com
https://old.example.com	*.example.*	*.example.com	old.example.com
https://an.old.example.com	*.example.*	*.example.com	an.old.example.com

Suggested presets for the preference group

"Random, temporary containers"

By default, any unmatched URL would be put into a newly minted, unique, random container that destructs after the last tab in the container is removed.

"Autocreate containers per domain"

Close #80

"Default container"

All unmatched URLs would end up in the same container. If I'm not mistaken this would fix #10

"Default temporary container"

Same as "Default container" with the change that once the last tab in the default container is closed, the default container would be closed. Fear not, the default container would be created again once an unmatched URL is encountered.

[ghost]

First generation from preferences.json

"Save" doesn't work yet, but that's coming

[NomDeMorte]

Having a single global default container carries problems of it's own. See #53 to pick the first example I found.

For example, right now I'm logged into github with two different accounts, in two different containers. If I open an unmatched URL from this container, I'd like it to be opened in the default 'No container', but if I opened that same unmatched URL in the other container, I'd like it to remain in that same container that I'm opening it from. Same URLs in both cases, but different behaviour based on the container.

But, I notice you mention in the UI that the default container name can be a variable. Is this to allow for a future featureset where the variable is stored in the ruleset, this implementing the entry and exit rulesets discussed here?

[ghost]

Hi @NomDeMorte

Thank you for your response. Your focus is on entry and exit rules. I don't think default containers, as I am going to implement them, will clash with that feature request.

Since you say you're a retired dev, I think a skeleton of some python code will be simpler here (since it's closer to pseudo code). Ignore the camelcase please.

def handleUrlChange(currentContainer, oldUrl, newUrl):
    
    if oldUrl.host == newUrl.host:
        return
    
    # Handle exit rules
    newContainer = currentContainer.exitRules.getContainer(newUrl)
    if newContainer:
        return createTab(newUrl, newContainer)
    
    # Handle entry rules
    newContainer = getContainer(newUrl)
    if newContainer:
        return createTab(newUrl, newContainer)
    
    # Default container being implemented
    newContainer = getDefaultContainer(newUrl)
    if newContainer:
        return createTab(newUrl, newContainer)
    
    # Default container not activated.
    # Nothing to do

I can ping you once I have implemented getDefaultContainer then you'll understand what the naming will do from the code. All it does is generate a name for the container. If you look at the examples in my first comment, you should get an idea.

[ghost]

Example of {domain} container name

[NomDeMorte]

Your focus is on entry and exit rules.

So is yours :) A global default container is a global exit rule.

If I'm understanding your pseudocode correctly, getDefaultContainer(newUrl) could just call .exitRules.getContainer(newUrl), where .getContainer() (the container class's member function) handles unmatched URLs - as should getContainer() (the global function) .... That being the case, there is no need for getDefaultContainer() to exist really.

It will be good if your implementation doesn't directly block other related feature requests... but it would also be a shame for your work to have to be removed and replaced with something else, in order to meet those requests, when the same amount of your work could instead apply some feature requests now (ie global exit rules), and have half of the work done for other feature requests (ie per-container exit rules).

I just want to make sure you are getting the best return on your investment of time, and also allowing future work to benefit from that investment.

[ghost]

Cheers. I'll try to recreate it.

[crssi]

What about save on change and no button at all?

Cheers

[ghost]

I think I'll go for the "save on change". It might be more intuitive indeed

[NomDeMorte]

Save on change is bad because if a user clicks something in error it's done. That's why Save/apply/close/etc buttons are standard.

[kristofferR]

Thanks for implementing support for No container, but unfortunately it's really wonky. It seems to still use the container functionality despite it's not being needed. The pages are quickly closed and reloaded, and the back button/history doesn't work at all.

Would it be possible for it to instead completely bypass the container functionality so that pages that open without a container function as normal?

[ghost]

@kristofferR It should work now.

[crestcere]

Hey, out of context but I want to try this. Can you publish compiled version of this branch? I want to use it.
Thank you.

[ghost]

@sungerbob this is the one I'm currently using containerise-3.5.3alpha.zip. I uploaded it to IPFS. If it goes down I'll find another host. It could be interesting to add builds to the CI 🤔 (but that would be in another PR)