1945207 - [macOS] External links are not opening in the active Firefox profile (in focus)

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Simona Badau, Desktop Test Engineering]

Found in

• Nightly 136.0a1

Affected versions

• Nightly 136.0a1

Tested platforms

• Affected platforms: macOS 15
• Unaffected platforms: Windows 11

Preconditions

• Create at least 2 profiles (Profile A and Profile B)
• Make Firefox the default browser.

Steps to reproduce

1. From Profile A, go to Hamburger menu -> Profiles and launch Profile B
2. Have Profile B in focus and open different web sites.
3. Click on a link from an external app (Skype)

Expected result

• The link from step 3 should be opened in a new tab on Profile B.

Actual result

• The link from step 3 is opened in a new tab on Profile A. For more details, please see the screen recording.

Regression range

• This is not a regression.

Comment 1

[Dave Townsend [:mossop]]

I think I know what's going on here.

Comment 4

[Dave Townsend [:mossop]]

Attachment: Bug 1945207: Open URLs passed via NSApplicationDelegate in the correct profile. r=jhirsch!

Unlike other platforms on macOS if Firefox is already running and an application wants to open a URL
it doesn't use a command line call. Instead the URLs are passed via the NSApplicationDelegate
instance, our implementation of that creates a new nsICommandLine and runs it through the existing
handlers. This entirely skips the startup logic for choosing the default profile and so URLs are
simply opened in whatever profile happens to be running. Not sure what the precise logic is when
multiple profiles are running, it seems like the oldest one wins, not the most recently used one
which is what we want.

Here we intercept the new command line, attempt to guess if we may need to send it to a different
profile and if so do so by using the normal command line approach which will then use the startup
logic to choose the correct profile to use.

One niggle to this is that macOS also automatically focuses the existing instance of Firefox prior
to sending us the URLs which causes us to immediately switch the default profile. This patch
introduces a delay to that so we process the URLs before the default profile can change.

Comment 5

[astrovink]

(In reply to Dave Townsend [:mossop] from comment #4)

Created attachment 9464667 [details]
Bug 1945207: Open URLs passed via NSApplicationDelegate in the correct profile. r=jhirsch!

Unlike other platforms on macOS if Firefox is already running and an application wants to open a URL
it doesn't use a command line call. Instead the URLs are passed via the NSApplicationDelegate
instance, our implementation of that creates a new nsICommandLine and runs it through the existing
handlers. This entirely skips the startup logic for choosing the default profile and so URLs are
simply opened in whatever profile happens to be running. Not sure what the precise logic is when
multiple profiles are running, it seems like the oldest one wins, not the most recently used one
which is what we want.

Here we intercept the new command line, attempt to guess if we may need to send it to a different
profile and if so do so by using the normal command line approach which will then use the startup
logic to choose the correct profile to use.

One niggle to this is that macOS also automatically focuses the existing instance of Firefox prior
to sending us the URLs which causes us to immediately switch the default profile. This patch
introduces a delay to that so we process the URLs before the default profile can change.

Ah, so does this mean you fixed it? Sorry I don't understand how bugzilla works very well lol. If so, when will the fix be available in nightly/dev/release? Thanks!

Comment 6

[Dave Townsend [:mossop]]

(In reply to astrovink from comment #5)

Ah, so does this mean you fixed it? Sorry I don't understand how bugzilla works very well lol. If so, when will the fix be available in nightly/dev/release? Thanks!

The patch is up for review. Once approved and landed it will be in the following nightly and will then follow the normal release cycle.

Comment 7

[astrovink]

Ah ok, thank you so much for your work on this!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b30669a3b55f
Open URLs passed via NSApplicationDelegate in the correct profile. r=jhirsch,profiles-reviewers

Comment 9

[Norisz Fay [:noriszfay]]

Backed out for causing bc failures on browser_update_profile_on_window_switch.js

Backout link

Push with failures

Failure log

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf880262fd72
Open URLs passed via NSApplicationDelegate in the correct profile. r=jhirsch,profiles-reviewers

Comment 11

[amarc]

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

Comment 12

[Simona Badau, Desktop Test Engineering]

Attachment: Screen Recording with the issue

I wanted to verify this on the latest Nightly 137.0a1, and indeed, the external link opens in the current profile. However, before that, the first opened profile briefly gains focus and flashes over the current one.

Please see the screen recording for more details.
Dave, is this expected behavior? Should I file a new bug?

Comment 13

[Dave Townsend [:mossop]]

(In reply to Simona Badau, Desktop QA from comment #12)

Created attachment 9467699 [details]
Screen Recording with the issue

I wanted to verify this on the latest Nightly 137.0a1, and indeed, the external link opens in the current profile. However, before that, the first opened profile briefly gains focus and flashes over the current one.

Please see the screen recording for more details.
Dave, is this expected behavior? Should I file a new bug?

Yes this is mentioned in comment 4. It isn't desirable but at the moment there doesn't appear to be any way to solve it.