[Feature Request] "Always open in" configurable using domain + path

[justrhysism]

Actual behavior

Setting "Always open in" for a particular site defaults to the entire domain, e.g. setting for https://dev.azure.com/MyCompany/ sets the entire domain of https://dev.azure.com/ to use that container.

Requested behavior

For those of us who manage multiple logins for multiple organizations, it would be awesome if we could (optionally) include the path to determine which container:

e.g.

https://dev.azure.com/MyCompany/ => My Company Container
https://dev.azure.com/OtherCompany/ => Other Company Container

[richardkmichael]

FWIW, I believe this fork has a similar feature. I have not tried it.

[rolandd]

+1 on this request - I have one different but very specific use case. Right now I have "nytimes.com" sites set to open in a "news" container and "thewirecutter.com" set to open in my shopping container. Unfortunately NYT recently changed the wirecutter to redirect to https://www.nytimes.com/wirecutter/ so if I go to "thewirecutter.com" then it ends up open in my news container (which is not logged into my shopping accounts etc). It would be ideal if I could say any pages matching "nytimes.com/wirecutter" get opened in shopping, otherwise anything matching nytimes.com goes into news.

[gkaklas]

@justrhysism I believe this seems like a duplicate of #473 and/or #691 🤔 If this is the case, I believe it is ok to close this

[nitrocode]

Seems like the full URL is stored in the browser

multi-account-containers/src/js/background/assignManager.js

Line 574 in 0bcac2a

async _setOrRemoveAssignment(tabId, pageUrl, userContextId, remove) {

multi-account-containers/src/js/background/assignManager.js

Lines 596 to 599 in 0bcac2a

	await this.storageArea.set(pageUrl, {
	userContextId,
	neverAsk: false
	}, exemptedTabIds);

But when it's retrieved, only the host name and the port is used.

multi-account-containers/src/js/background/assignManager.js

Lines 12 to 20 in 0bcac2a

	getSiteStoreKey(pageUrlorUrlKey) {
	if (pageUrlorUrlKey.includes("siteContainerMap@@_")) return pageUrlorUrlKey;
	const url = new window.URL(pageUrlorUrlKey);
	const storagePrefix = "siteContainerMap@@_";
	if (url.port === "80" || url.port === "443") {
	return `${storagePrefix}${url.hostname}`;
	} else {
	return `${storagePrefix}${url.hostname}${url.port}`;
	}

This might be one of the code changes needed

  if (url.port === "80" || url.port === "443") {
-    return `${storagePrefix}${url.hostname}`;
+    return `${storagePrefix}${url.hostname}${url.pathname}`; 
  } else {
-    return `${storagePrefix}${url.hostname}${url.port}`; 
+    return `${storagePrefix}${url.hostname}${url.port}${url.pathname}`; 
  } 

https://developer.mozilla.org/en-US/docs/Web/API/URL

It would be more work to make it configurable in case some users wanted to use just the hostname (current) or both hostname and path

[mejo-]

This would be incredibly helpful e.g. for Github/Gitlab if you use different handles for different projects. github.com/projectA would open in one container and github.com/projectB in another.

[rjt]

Trying to understand here, was there a strong developer reason to not use the pathname of the url?

[achernyakevich-sc]

@rjt Probably problem is not laying in these line (though if I properly remember url.pathname was not available in early versions of Firefox API). :)

As soon as you introduce support of path name you will need to add its support in the URL assignment UI and whole UX. And it is not only one editor but it will touch almost all visual part of MAC add-on. Be sure that it is a quite big bunch of work that could cause add-on instability. As this add-on is Open Source and is maintained by volunteers I could not expect that these guys have so much free time for it.