1874599 - Links opened from external applications no longer respect Multi Account Container addon "Always Open This Site In..." setting

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[M]

Steps to reproduce:

I have a tab open to domain.tld in a named container, let's say "Work".

I have avoided setting the "Always Open This Site In..." setting for domain.tld to point to the "Work" container, because I don't want cross-contamination between external links and the "Work" container.

Actual results:

Currently if I click a link in an external application, Firefox does not respect my choice of not setting "Always Open This Site In..." and opens the external domain.tld link in the "Work" container.

Expected results:

Firefox should respect my choice of not setting "Always Open This Site In..." and not open links in a container. At least a config to turn this off would be nice.

Comment 1

[M]

I consider this a regression, but this seems to be a feature (request) https://bugzilla.mozilla.org/show_bug.cgi?id=1692124

However I understand if this is considered a feature request and not a regression.

As a side note, this also breaks the extension Temporary Containers, where it is especially problematic, as it causes privacy leaks when links won't open in a new Temporary Container, but are forced to open in an arbitrary named container instead.

Comment 2

[M]

Another question I have, which may be a dumb question as I do not understand the inside workings of this, but why wasn't the "Always Open This Site In..." feature not used to resolve https://bugzilla.mozilla.org/show_bug.cgi?id=1692124 but instead the guessing functionality was introduced, which can not be turned off?

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Richard Schwab]

This is especially a problem when you have URLs that perform automatic authentication flows through an SSO provider.

I've got multiple accounts at my employer's IDP for different purposes, such as testing things.
I've been using no container as my default browsing context, which I'm using with my primary account at this IDP.
Additionally, I have containers that I use other accounts at the same IDP in.

Since this was introduced, I've frequently run into the issue that our VPN client initiates an SSO login flow, which firefox now incorrectly attributes to one of the dedicated extra account containers instead of using no container.
If I'm already authenticated at the IDP in this container, this will result in a seamless redirect and end up in me connecting to the VPN with an incorrect identity.

The only way to intercept this is to either mash escape at the right time to prevent the redirect from loading properly (and not do it too early that it nukes the URL from your address bar) or to explicitly logout from the IDP in the container, so I can reopen the address outside of the container, as it will not seamlessly redirect while requiring me to provide credentials.

Comment 5

[piercemind]

Container autoguessing introduced by https://bugzilla.mozilla.org/show_bug.cgi?id=1692124 must be configurable; imo it adds more harm than benefit.

Comment 6

[piercemind]

(In reply to piercemind from comment #5)

Container autoguessing introduced by https://bugzilla.mozilla.org/show_bug.cgi?id=1692124 must be configurable; imo it adds more harm than benefit.

Forgot to mention an example. There is a container without sites bound to it ("Container site list" is empty). A few urls are opened in this container, manually. "Heuristics" from https://bugzilla.mozilla.org/show_bug.cgi?id=1692124 puts externally clicked links of the same site in that container. It definitely is not a desired behaviour, considering there is no site-container binding config.

Comment 7

[Brian Grinstead [:bgrins]]

Attachment: Screenshot 2024-01-16 at 9.24.56 AM.jpg

Looked briefly into this. STR

1. Install https://addons.mozilla.org/en-US/firefox/addon/multi-account-containers/
2. Open https://www.mozilla.org/en-US/privacy/firefox/
3. Click on the addon's container icon in the URL bar ("Always Open This Site In...") and select e.g. Personal.
4. Open two new tabs in e.g. Work and load https://www.mozilla.org/en-US/privacy/firefox/. Note the interstitial UI confirming you actually want to load it here (see screenshot)
5. Click a link to https://www.mozilla.org/ from an email client or other external opener
6. This opens the same interstitial as in (4)

I haven't looked into how the addon works, but the code in Bug 1692124 is running before any addon logic (and before a tab gets added in the first place). I could imagine querying these site specific settings, but off hand that seems a bit unusual to do in a browser module.

Comment 8

[Brian Grinstead [:bgrins]]

(In reply to Richard Schwab from comment #4)

This is especially a problem when you have URLs that perform automatic authentication flows through an SSO provider.

I've got multiple accounts at my employer's IDP for different purposes, such as testing things.
I've been using no container as my default browsing context, which I'm using with my primary account at this IDP.
Additionally, I have containers that I use other accounts at the same IDP in.

Since this was introduced, I've frequently run into the issue that our VPN client initiates an SSO login flow, which firefox now incorrectly attributes to one of the dedicated extra account containers instead of using no container.
If I'm already authenticated at the IDP in this container, this will result in a seamless redirect and end up in me connecting to the VPN with an incorrect identity.

The only way to intercept this is to either mash escape at the right time to prevent the redirect from loading properly (and not do it too early that it nukes the URL from your address bar) or to explicitly logout from the IDP in the container, so I can reopen the address outside of the container, as it will not seamlessly redirect while requiring me to provide credentials.

I understand this is frustrating - in fact, this is exactly the type of issue that Bug 1692124 is meant to address - the previous behavior had the same outcome when the IDP login was in a container and not the default browsing context. While we can take steps to improve the heuristic (e.g. tagging history with container ID in Bug 1283320 and then using frecency to have better guesses, or taking the container of the currently focused tab into consideration), nothing (including the previous behavior) is going to perfectly predict which container to put a page in, short of an interstitial UI and user interaction (which is a lot of work to get right, and even then has challenges like additional friction or confusion if it's triggered unnecessarily).

So what I propose we do here is add a single new pref which will restore the old behavior (ignore all heuristics and just open in default browsing context ID), so that people can restore the old workflow if they wish.

Comment 9

[Brian Grinstead [:bgrins]]

Attachment: Bug 1874599 - Add a pref to disable userContextId guessing for external opens;r=mossop

Bug 1692124 improved the behavior for workflows where external opens should move into sessions
inside containers, but it created an issue for those where external opens should move into
the default container and there are also tabs from the same domains inside containers, and
would create extra interstitials with the Multi-Account Containers addon if the predicted
container is different than the "always open" addon setting.

While the heuristic could be improved, it will never be perfect for all workflows,
so this patch introduces a pref to opt out of the behavior (and always open external
links in the default user context ID).

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1692124

Comment 11

[Donal Meehan [:dmeehan]]

Could this be triaged for severity?

Comment 12

[Ina Popescu, Desktop QA]

I'm not able to reproduce the issue described in Comment 0 in Firefox 122.0 on Windows10 x64.
When I select the option Always open this site in… to open for example https://www.mozilla.org/en-US/privacy/firefox/ in Work container, next time when accessing same link from an external application, the prompt Open this site in your assigned Container? appears.
Otherwise, without selecting first the option Always open this site in…, the link in question is opened in no container.
Is it possible to provide a video with the behavior you're seeing?

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a1025a4ef39f
Add a pref to disable userContextId guessing for external opens;r=mossop

Comment 14

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/a1025a4ef39f

Comment 15

[Brian Grinstead [:bgrins]]

Update: you can prevent the new behavior by setting the browser.link.force_default_user_context_id_for_external_opens pref to true

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:bgrins, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox123 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Brian Grinstead [:bgrins]]

Comment on attachment 9376147 [details]
Bug 1874599 - Add a pref to disable userContextId guessing for external opens;r=mossop

Beta/Release Uplift Approval Request

• User impact if declined: For users with Multi Accounts Container addon, and who keep relevant sites opened inside of "No container", the current behavior will cause those sites to open inside of containers if they already have another tab with the same site in a container (since MAC doesn't offer the option to pin a site into no container). There's not to a perfect heuristic here, so as a workaround we landed a pref to disable all heuristics and just open in no container - restoring previous behavior.

This doesn't affect many users, and we could leave it out of 123 if it's too late to uplift, but I received a request from a user asking if we could uplift, and it's a low risk change, so figured it's worth requesting.

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The updated behavior is behind a non-exposed pref, and it's covered by tests
• String changes made/needed: None
• Is Android affected?: No

Comment 18

[Brian Grinstead [:bgrins]]

STR if we do want to manually verify:

Default behavior:

• Open https://www.mozilla.org/en-US/ in a container
• Open https://www.mozilla.org/en-US/ from an external app (email client, messenger, note)
• The new link should open in the same container

Preffable behavior:

• Set browser.link.force_default_user_context_id_for_external_opens to true
• Open https://www.mozilla.org/en-US/ in a container
• Open https://www.mozilla.org/en-US/ from an external app (email client, messenger, note)
• The new link should open in no container

Comment 19

[Pascal Chevrel:pascalc]

Comment on attachment 9376147 [details]
Bug 1874599 - Add a pref to disable userContextId guessing for external opens;r=mossop

Approved for 123 beta 9, thanks.

Comment 20

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/2994ba711bf0

Comment 21

[Ciprian Georgiu, Desktop QA]

I have reproduced this issue on macOS 14 with Release 122.0, following STR from comment 18.

The issue is verified as fixed on latest Nightly 124.0a1 and Beta 123.0b9 under macOS 14, Ubuntu 22 and Win 11.