Multi-account-containers: "Always open in <container>" should respect URL path

[mkurz]

I want to sign in to Google Maps with a different account than to google.com:
https://www.google.at/maps/
https://www.google.at/

However as soon as I run "Always open in \" for the /maps/ path also the whole domain gets locked into that container. I also tried the lock google.at into a different container afterwards, however that also changes the /maps/ container as well again...

[erjiang]

How do you propose users choose between whether they want to create a rule for the entire domain or just for a subdirectory?

[brunoais]

Allow the creation of rules using pattern matching while providing some
defaults.
Allow specifying patterns in the "office way" (using "*", "?" and "!") and
regex for the more advanced people.

Put that option available in an options page (accessible in the extension's
popup page) by a button/link on the element that contains the container's
name and color.
Pressing the button or link will open a popin that will allow the user to
insert the rules he wants to insert.
I suggest having a whitelist and a blacklist.
Blacklist has priority towards whitelist.

By default, both are empty, which means it matches no urls.
Adding url patterns to the whitelist will make them match (and select that
container as the one).
Adding url patterns to the blacklist will make them match and make that tab
not be placed in that container (by this system), regardless if they
matched in the whitelist.

Make it so the user can specify multiple rules that add to each other using
an OR (for example, one per line).

Any opinions?

On Thu, Nov 30, 2017 at 1:19 AM, erjiang [e-mail] wrote:

How do you propose users choose between whether they want to create a rule
for the entire domain or just for a subdirectory?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mozilla/multi-account-containers/issues/976#issuecomment-348051828,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnB632E4bY499ICQhCN1tT7ASIqk4Dyks5s7gKogaJpZM4Qh38A
.

[groovecoder]

See also https://github.com/mozilla/multi-account-containers/issues/473

[mkurz]

@groovecoder What does the assignment label mean?

[groovecoder]

Just that this issue is related to the site assignment feature.

[jakecoppinger]

Functioning work around I found after struggling with this:

• Disable WiFi/network
• Open tab of the container of your choosing
• Open maps.google.com, it will error and keep the domain
• Go Containers menu -> Always Open in <Your Container> (don't worry about the Error page title)
• Re-enable network

Now https://www.google.com/search?q=test will stay in default container, and maps.google.com will _change container, and then redirect_ to https://www.google.com/maps!

[mkurz]

@jakecoppinger Unbelievable, it's working! Thank you very much for sharing this workaround! I am curious, how did you find out?

[jakecoppinger]

Oh wow, first time I've got a thumbs up to a comment! Glad to have helped!

@mkurz I started playing around with containers this evening and I could see that the Always Open In... mapping of URLs to containers was storing the redirected domain. I tried hitting maps.google.com and stopping the page load as fast as I could so that I could store the different base URL but I couldn't stop it in time. I tried disabling my WiFi to stop the redirect as I couldn't find network throttling in the devtools and the error page title doesn't matter, so it seems that the base URL is the key rather than the page title.

I don't think it would work for differentiating http://example.com/test1 and http://example.com/test2 as these have the same base URL, but it should differentiate http://example.com/test1, http://test1.example.com and http://test2.example.com

[mkurz]

@jakecoppinger Thanks!

I just found out we could probably also simply edit the file ~/.mozilla/firefox/<profile-id>/browser-extension-data/@testpilot-containers/storage.js by hand to achieve a desired behaviour. Seems that is the file which stores all the container data.

[groovecoder]

This is a duplicate of https://github.com/mozilla/multi-account-containers/issues/691

[GJRobert]

@jakecoppinger Thanks!

I just found out we could probably also simply edit the file ~/.mozilla/firefox/<profile-id>/browser-extension-data/@testpilot-containers/storage.js by hand to achieve a desired behaviour. Seems that is the file which stores all the container data.

Editing this file directly works (must quit the browser first), thanks. For example, find the following string in that file like:
siteContainerMap@@_github.com
and append subdirectories or other part of the URL to be like
siteContainerMap@@_github.com/mozilla/multi-account-containers/issues/473
so to always open this issue in a certain container, while keeping other github.com URLs unset.

[Update 2019/1/4]
The method mentioned above is not working any more in Waterfox 56.2.6. Weirdly. Sad.

[StefanSchoof]

For things like http://example.com/test1 and http://example.com/test2 you can use the Containerise addon to configure this. (found in https://github.com/mozilla/multi-account-containers/issues/473#issuecomment-524319820)

[GJRobert]

For things like http://example.com/test1 and http://example.com/test2 you can use the Containerise addon to configure this. (found in #473 (comment))

Hi,
I haven't been able to make the mentioned behavior work in my Firefox 68 with Containerise installed. Could you?