Open Link in New Container Tab always opens site in a container assigned to the site

[quiet23]

Hi, I don't know if this is an intended behavior.
I have a page opened does not matter in the Default or another container. The page has a link to a site that is configured in the add-on to be automatically opened in 'container1' container. When I try to open the link in a new tab in a container different from 'container1' using context menu ("Open Link in New Container Tab"->'container2') the link is always opened in 'container1'.
I expect context menu action to have priority over the container setting option for a site, because if I use context menu to open a link in a certain container then it is necessary for me now to open the link in that exact container. What do you think about the add-on behavior, is it a bug?

Steps to reproduce:

• open youtube.com in a container (let's call it 'Google'), check both checkboxes "Always open in Google" and "Remember my decision for this site";

- open the following page in a tab (does not matter in the Default container or any other one): https://support.google.com/youtube/answer/57407?co=GENIE.Platform%3DDesktop&hl=en - right click on the link "Upload to Youtube", choose "Open Link in New Container Tab"->Shopping;

- the link opens in the container 'Google':

All the required information about my browser is attached below.
about_support_output.txt

[stoically]

I'd personally say that "Remember my choice" is like a "hard-lock" to that specific container. If you want to have the choice, then don't click "Remember my choice" and you get to choose. Although - the context menu should probably reflect that to not give the impression it's possible to open in another container.

"Forgetting" that choice is currently only possible by unticking+ticking the "Always open in" checkbox. Related: #1111

[quiet23]

The way you are offering to workaround the add-on behavior is very slow and inconvenient. It requires to do additional click not only when I need to open the hard-locked site in another container, but also when the site is to be opened in the assigned container.
Let me just describe my use case of the add-on that had led me to the non-functioning context menu. I use the add-on to isolate a social network site in a separate container. The social network site contains external links that are wrapped into request to their tracking site (so link like https://google.com becomes somewhat like https://vk.com/track?=google%2Ecom), so when I try to open such link it opens in a container assigned to the social network. All the effort to isolate the site is pointless because of the add-on behavior. Even opening a new tab in the container dedicated to ordinary sites and pasting the wrapped link into the address field of the tab does not help because of the vk.com site container being hard-locked. I can only workaround the issue by using different browser (!) to open the links.
So it's up to you devs to decide if the use case is worth to be noted or not.

[stoically]

The social network site contains external links that are wrapped into request to their tracking site (so link like https://google.com becomes somewhat like https://vk.com/track?=google%2Ecom), so when I try to open such link it opens in a container assigned to the social network.

That's actually a bug introduced with the patch for opening multiple tabs #1114. What should happen, and what happened before version 6.0.0 is that it'll open the confirm page if "google.com" is assigned to another container than the one where you open the link (vk.com/?track=google.com in this case) in. I'll look into it right away - thanks for reporting. I was confusing something here. It actually works as intended. So scratch that. What I've experienced is #1137

[stoically]

If I understood you correctly you want to right-click on tracking links and be able to open them in another container despite being "hard-locked" to the underlying tracking-domain and with a redirection target that is not assigned. That is imho indeed a valid use-case and worth thinking about.

So currently the only workaround for that exact scenario where vk.com is "hard-locked" and uses an outgoing tracker on the same domain is to assign the redirection target (google.com in your example) to another container because that will trigger the confirm page. What also possibly could help here is an "Isolation Mode" that would only allow assigned domains to load in a container - which is something I'm working on for the Temporary Containers Add-on. Not sure if that's something MAC wants to implement too, but I think it might be a good fit.

[quiet23]

If I understood you correctly you want to right-click on tracking links and be able to open them in another container
Yes, I'd like to be able to do exactly that to prevent opening external links in the same container with vk.com.
Thank you for suggesting the Temporary Containers Add-on, I don't quite understand how the "Isolation Mode" feature works (in particular, how it will handle redirects), but will give it a try when it's released. Thank you for your help again.

[groovecoder]

So, the expected behavior here is that "Open Link In Container Tab" should override the assignment.

This may be possible to fix if we can detect the webNavigation.TransitionType type when the user clicks "Open Link In Container Tab ->".

Also maybe helpful: https://bugzilla.mozilla.org/show_bug.cgi?id=1215376

[stoically]

@quiet23

I don't quite understand how the "Isolation Mode" feature works (in particular, how it will handle redirects), but will give it a try when it's released.

The Isolation feature lets you decide when navigating in general or on a specific website should open a new Temporary Container based on the navigation target. The "Multi-Account Container Isolation" makes it so, that if a request in a permanent container happens and the URL the request tries to load isn't assigned to "Always open in" for that container, then a new Temporary Container will be opened. This also affects the redirects in your use-case. Both is available in the new version 0.67 of Temporary Containers in the Options under "Isolation". Feel free to come back to me if something doesn't work as expected or is unclear.

I've also realized that Multi-Accoint Container Isolation based on assignments isn't too easy to handle UX-wise. If enabled you can't assign new websites anymore because you can't load them in the first place in a permanent container without being assigned. So yeah, I guess that would need some work.

Isolation aside, to fix this bug contextMenus.onClicked could help too.

[stoically]

Just realized that neither contextMenus.onClicked nor onBeforeShow would help in this case, since the "Open Link in New Container Tab" context menu isn't part of the Add-on and those events only fire for context menus registered from the Add-on. So if TransitionType should get a "context_menu" type, that would probably the way to go

[Etrit1]

I'm 90% sure this is only a problem with Google. (or sites that track you like they do). I'm not having the issue with Facebook.

I haven't told Firefox to always open Google tabs in a Google container. I just opened a container, went to Google, did a search and used the Context menu to open a link in a new tab in a different container... and it just opened it in the same container as Google.