2036237 - URL from Apple Event / command line is lost when old profile manager dialog relaunches Firefox

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Logan Rosen [:Logan]]

When Firefox is launched via open https://example.com (or Python's webbrowser.open()) on macOS and the old profile manager dialog appears (due to StartWithLastProfile=0 in profiles.ini), the URL is not loaded after selecting a profile.

Steps to reproduce

1. Ensure StartWithLastProfile=0 is set in profiles.ini (or have the old profile manager configured to show on startup)
2. Ensure Firefox is not already running
3. Run: open https://example.com (or open -a "Firefox Nightly" https://example.com)
4. The old profile manager dialog appears
5. Select a profile and click "Start Firefox"

Expected

Firefox opens and navigates to https://example.com

Actual

Firefox opens to a blank new tab. The URL is lost.

This was encountered in practice when ./mach try auto opens a Lando auth URL via webbrowser.open() and the profile manager intercepts the launch.

Affected versions

Reproduced on both Firefox Release and Firefox Nightly on macOS.

Comment 1

[Logan Rosen [:Logan]]

This appears to be a regression from bug 1866098 ("Run NSApp earlier in startup").

The old code called ProcessPendingGetURLAppleEvents() DURING SetupMacCommandLine(), which would spin the event loop to process pending Apple Events at exactly the right moment. openURLs: used AddURLToCurrentCommandLine() to add URLs directly to the command line being built.

Bug 1866098 replaced this with a two-phase approach: collect URLs early via InitializeMacApp() (which runs [NSApp run] briefly), then consume them later via TakeStartupURLs() in SetupMacCommandLine(). But this introduced a timing gap — if the Apple Event arrives after InitializeMacApp()'s [NSApp run] exits (which happens because applicationDidFinishLaunching: calls [NSApp stop:]), the URL misses the collection window.

This affects all cold starts on macOS where a URL is provided via Apple Event (e.g. open https://example.com), not just the profile manager case. The profile manager makes it more visible because the URL needs to survive a process relaunch.

Comment 2

[BugBot [:suhaib / :marco]]

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

:eeejay, since you are the author of the regressor, bug 1866098, could you take a look?

For more information, please visit BugBot documentation.

Comment 3

[Logan Rosen [:Logan]]

mozregression bisection complete. This is NOT a regression from bug 1866098.

Regression range:
Last good: e9458609191d (2025-09-29)
First bad: e7010b54fe0e (2025-09-30)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e9458609191d42bae5f4883d9226e2ecc21a361a&tochange=e7010b54fe0ee4432bda8f36e9f7df623319ff9c

The regressing commit is Bug 1988774 - "Update macOS SDK for tahoe" (cc06e453846c). This only changes the macOS SDK version from 15.5 to a newer one. The SDK change appears to have altered how NSWorkspace's openApplicationAtURL:configuration:completionHandler: handles command-line arguments passed via [config setArguments:]. With the older SDK, -url arguments survived the LaunchChild -> updater -> NSWorkspace relay. With the newer SDK, they do not.

This means the bug is in how the macOS Tahoe SDK handles app relaunch arguments through NSWorkspace, and the fix likely needs to find an alternative way to pass the URL through the profile manager relaunch.

Comment 4

[Donal Meehan [:dmeehan]]

Changing need-info to assignee of Bug 1988774

Comment 5

[Emilio Cobos Álvarez [:emilio]]

I'm not familiar with app launch shenanigans on macOS... Stephen, do you know how might the right fix look like here? It's a bit surprising (but plausible) that an SDK update changed behavior here... I don't see anything documented at least from the release notes...

Dave, ni?ing you since you're familiar with launch and the profile manager, in case there might be something obvious going on...

Comment 6

[Logan Rosen [:Logan]]

Attachment: Bug 2036237 - Fix URL loss from Apple Events on macOS r=#mac-reviewers

On macOS 15 (Sequoia), NSWorkspaceOpenConfiguration's setArguments: is
deprecated and no longer forwards command-line arguments to child
processes. This caused URLs from Apple Events (e.g. open https://...)
to be lost when Firefox relaunches itself through the profile manager.

Two issues needed fixing:

1. The updater binary (used as a relaunch helper) passes -url arguments
   to Firefox.app via NSWorkspace's setArguments:, which no longer works.
   Fix this by extracting -url arguments and delivering them via
   openURLs:withApplicationAtURL:configuration:completionHandler:
   instead, which sends them as Apple Events to the child process's
   application:openURLs: delegate.

2. The child process's openURLs: handler only buffered URLs during the
   brief InitializeMacApp() run loop (LaunchStatus::CollectingURLs).
   URLs arriving later (e.g. via Apple Events from the updater) were
   dispatched immediately via nsICommandLineRunner, which fails during
   early startup. Fix this by adding a new LaunchStatus::Running state
   and buffering URLs for all pre-Running states. The transition to
   Running happens after SetupMacCommandLine has consumed startup URLs.

Co-authored-by: Copilot <[e-mail]>

Comment 7

[Emilio Cobos Álvarez [:emilio]]

So the diagnostic in comment 0 changed from what's in phab. The patch is now tweaking the code from bug 1866098. Does it mean that bug is the regressor after all?

Comment 8

[Emilio Cobos Álvarez [:emilio]]

(or is it something else like the sdk changing some timing or behavior during startup?)

Comment 9

[Logan Rosen [:Logan]]

To answer the question from comment 7/8:

Bug 1988774 (SDK update) is the regressor, not Bug 1866098. Here's what happened:

Bug 1866098 introduced the InitializeMacApp() pattern: call [NSApp run] briefly to collect URLs from Apple Events, then applicationDidFinishLaunching: calls [NSApp stop:] to exit the run loop. The code assumes application:openURLs: fires before applicationDidFinishLaunching: (the comment at MacApplicationDelegate.mm:267-269 states this explicitly).

The macOS 26 SDK changed NSApplication.finishLaunching() from dispatching pending Apple Events (kAEOpenDocuments) synchronously inline -- which allowed application:openURLs: to fire before applicationDidFinishLaunching: -- to posting them to the event queue. Since [NSApp stop:] exits the run loop before those queued events are processed, the URLs are never collected.

This appears to be an undocumented SDK-linked behavioral change (Apple's release notes for macOS 26.0-26.4 don't mention it). Bug 2009594 reported the same symptom in January 2026 ("Open URLs from external applications no longer open on MacOS Firefox Nightly 148.0a1") but was closed INCOMPLETE.

Our fix adds a LaunchStatus::Running state so that openURLs: buffers URLs for all pre-Running states, not just CollectingURLs. This means URLs arriving after [NSApp run] exits but before the browser is fully started are still captured by TakeStartupURLs() in SetupMacCommandLine().

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/88dd3ac376c5
https://hg.mozilla.org/integration/autoland/rev/ed4ab6f89521
Fix URL loss from Apple Events on macOS r=mac-reviewers,bradwerth

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/40873380a531
https://hg.mozilla.org/integration/autoland/rev/29edf41ae210
Revert "Bug 2036237 - Fix URL loss from Apple Events on macOS r=mac-reviewers,bradwerth" for causing mochitest failure @ test_apple_event_url.py TestAppleEventURL.test_apple_event_url_survives_profile_manager

Comment 13

[Norisz Fay [:noriszfay]]

Backed out for causing mochitest failure @ test_apple_event_url.py TestAppleEventURL.test_apple_event_url_survives_profile_manager

Backout link

Push with failures

Failure log

Comment 14

[Logan Rosen [:Logan]]

Apologies – I re-requested review on Phabricator without the flaky test. It unfortunately seems that this is too difficult/flaky to test via Marionette.

Comment 15

[BugBot [:suhaib / :marco]]

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

Comment 17

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/5eabf666b2e8

Comment 18

[BugBot [:suhaib / :marco]]

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox152 to wontfix.

For more information, please visit BugBot documentation.