Proposal: separate 'force' and 'allow' domain lists per container

[kurahaupo]

Feature request

The current Limit to designated sites only option is a bit too restrictive.

In respect of a given container, it is reasonable to categorise a domain in at least 3 ways:

1. forced into the container, unless it's in the current container's allowed list;
2. forced out of the container;
3. allowed to remain in the container it's already in, without forcing it out of other containers;

Currently, domains in the designated sites list are always treated as category (1), and all other domains are either category (2) (when "limit to designated sites" is enabled) or category (3) (when it's disabled).

Sometimes it is preferable to allow some (known) secondary/resource sites to be loaded in multiple containers. That is, I want some way to have the full three-way categorisation of domains in respect of a container.

I would implement this in two parts:

• a secondary "allow" list on each container, which allows but does not require sites to be loaded in that container.
• a "universal allow" list, of domains that can be loaded into any container (to be used sparingly).

I would also have an option to clone a container with its secondary allow list but without its primary enforced list. And when adding a domain to the "force" list, if it already exists in the force list of another container, prompt the user and (if agreed) it should be removed from the other container.

Alternatively to having two lists per domain, have one list, and a checkbox on each entry labelled something like "share with other containers"

[draggeta]

This would be a great feature in my opinion.

I have multiple separate containers that shouldn't share websites. However, authentication for some of these websites is performed using EntraID. Being able to lock each container to only the list of forced containers and the allowed EntraID login page would be a boon.

[Totogro]

Related issue : https://github.com/mozilla/multi-account-containers/issues/2706 "When a site is set to always open in another container, there is no way to override that without completely removing it from the always open in container list"

[kurahaupo]

Having the lists isn't a full solution; we still need some reasonable way of editing them.

Without that we won't solve the problem with ancillary resources (css, js, images, frames) not loading because they're forbidden by the “Limit to Designated Sites” option, when there's no obvious method to add them to the Designated Sites list.

(Advanced users can use Firefox's debugger to find these resources and their domains, and can then add each resource domain to the container's Designated Sites by manually loading it in a separate tab, but that's really messy and not something ordinary users should be expected to follow.)

[kurahaupo]

Following on from some comments in #2706...

It seems like it would be preferable to avoid multiple lists, and therefore to show a single list of domains (per container) with each entry having two checkboxes, perhaps labelled something like “use this container when forbidden elsewhere” and "only in this tab" (and all per-tab domains are forgotten when the tab is closed).

In the code I would refer to that checkbox as primary to be succinct. (I previously suggested "allow" and "force" but I now think these could be misleading. It's important that whatever terminology is chosen makes clear that this category is always a subset of the "allowed" category. Perhaps "keep" and "primary keep"?)

Having separate lists under the hood makes the implementation simpler:

• a single “primary” list that maps domains to containers, and
• a per-container set of "kept" domains (or a two-level structure that maps containers to sets of domains), and
• a per-tab set of "temporarily kept" domains, which are added to whenever the user explicitly asks for a domain to be opened in a container (this is new, and intended to form the basis of a possible solution to #2706)

So then the logic to open a given domain is simply:

1. if this was pursuant to an explicit "open in container" request made by the user, the domain is re-opened in that container, with the domain added to the "temporarily kept" set for the resulting new tab;
2. if the domain is in the "allowed" list of the current container or the current tab, then we're finished: it won't be reopened in another container;
3. otherwise, if a domain has a "primary" container, and it's in the "keep" set for that container, then reopened the domain in that container;
   • optimisation: delete the domain from the primary map when it's found to be missing from the applicable "keep" set; and to prevent a race condition, always add a domain to the keep list before setting its value in, or adding it to, the primary map;
4. otherwise, if the current container is marked as "allow only designated sites", then the domain will be reopened in the default container.

If none of the above applies, then simply open in the current container.

[kurahaupo]

I would also suggest that it be possible to view (and perhaps edit) the list of containers where a domain can be kept, with a radio button to select which one is primary.

If no container is designated as primary, then this should result in "always ask".

Answering the "open in" dialog may result in the domain being added to the relevant keep list.

Moreover, the "default" (or "not in a") container should appear to behave like any other container for the purposes of this logic.