After bug 639707, it is my understanding that Firefox should automatically restart itself if it was open when the OS restarted for an update. I use Nightly, and for both the macOS 13.3 update, and the 13.3.1 updates, I have purposefully left Nightly open thinking it would auto restart after the update. However, that has not happened in my experience. Other apps, such as Slack, do re-open themselves.

Telemetry seems to indicate that this works at least "sometimes". Now we need to figure out when this does not work and fix those situations. Could you tell us what you have set for the following settings in about:preferences?

"Open previous windows and tabs"
"Confirm before closing multiple tabs"
"Confirm before quitting with ⌘Q"

(In reply to Stephen A Pohl [:spohl] from comment #1)

Telemetry seems to indicate that this works at least "sometimes". Now we need to figure out when this does not work and fix those situations. Could you tell us what you have set for the following settings in about:preferences?

Sure!

"Open previous windows and tabs": Enabled
"Confirm before closing multiple tabs": Disabled
"Confirm before quitting with ⌘Q": Disabled

I'm going to try and gather more info about the systems that seem to successfully use this feature using telemetry. However, I need to wrap up a few other tasks first. Setting n-i to keep this on my radar.

(In reply to Sam Johnson from comment #2)

"Open previous windows and tabs": Enabled
"Confirm before closing multiple tabs": Disabled
"Confirm before quitting with ⌘Q": Disabled

I've seen the same today and my settings are the following:

• "Open previous windows and tabs": Enabled
• "Confirm before closing multiple tabs": Disabled
• "Confirm before quitting with ⌘Q": Enabled

I've restarted again with a build as started via mach run so that it has all the default preferences. And even here it is not working. The instance doesn't get reopened after a restart.

Btw. note that Thunderbird actually perfectly gets reopened after the restart, and that already for some time.

(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #5)

I've restarted again with a build as started via mach run so that it has all the default preferences. And even here it is not working. The instance doesn't get reopened after a restart.

I don't believe that mach run will be a reliable way to test this feature. The application should be launched from the dock before testing.

I see. But creating a dock icon for the eg. artifact build and starting it by clicking on that icon should make it work, right?

We don't know in what ways application identifiers may or may not interfere with this feature at the moment. It is possible that only officially branded builds work. It is also possible that only builds with the "firefox" identifier might work, rather than "nightly". Telemetry seems to indicate that it works for both, but we haven't been able to narrow down what parameters make this work and when it doesn't.

I tried with a release build of Firefox 113 and it doesn't work as well. It's not getting reopened after the startup. Note that Thunderbird works fine for already quite some time...

I just noticed this again with the 13.4 update. Is there some logging I can produce before initiating the next macOS update that would be useful for identifying the issue?

Reporting back in that Nightly did not resume after the 13.5 update either.

This might be a factor. @Sam and @Henrik, do you launch the browser to the profile manager to start it? i.e., you do not have a default profile that gets used by default when starting the browser.

It's unofficially documented that you can see the list of apps which will be restarted by running

$ defaults -currentHost read com.apple.loginwindow TALAppsToRelaunchAtLogin

or by looking at the loginwindow's plist file with $ plutil -p ~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist

And I noticed that Firefox doesn't get put in the list if I launch it from the dock and select my profile. If I launch it and provide the profile on the command line using the open command, it does get added to the list. Note, the open command is a way to launch/open things from the command line that is meant to be equivalent to launching/opening through the finder. You can do this with a Firefox repo using $ ./mach run --macos-open.

So this $ open /Applications/Firefox.app/ --args -P MyReleaseProfile populates the file with Firefox.

But this $ open /Applications/Firefox.app/ does not. I have several profiles and none of them are set to be the default.

I have a default profile and do not launch to the profile manager. However, since I use Nightly, ~every launch of the browser is from the update notification, so I am not using the dock icon either.

When I ran defaults -currentHost read com.apple.loginwindow TALAppsToRelaunchAtLogin, Nightly was not in the list of apps, and it was last started via the update notification. Quitting Nightly and then opening it via the dock icon caused it to appear in the list.

Thanks, Sam.

After digging into this a bit more, I've found that the method we use to relaunch the browser after an update [NSTask launchedTaskWithLaunchPath:<path to the firefox executable> ...] does not result in Firefox being added to the resume list described in comment 13. This method is deprecated as of macOS 14. The call site in updater code is here and there may be other sites.

Using the newer [[NSWorkspace sharedWorkspace] openApplicationAtURL:<path to Firefox.app> ...] does result in the browser being added to the resume list. This method is available on 10.15+ which is now the minimum supported OS version for Release. With openApplicationAtURL, we shouldn't need to use the arch utility to launch because openApplicationAtURL uses the application's preferred architecture by default.

Assuming adopting openApplicationAtURL is the fix we use, we will want to find all the call sites where we launch the browser and change them to use the new method. Launches after updates and after profile-selection are the two that seem highest priority.

I'm always opening Firefox via the dock and yes the profile manager is always in use. This also explains comment 10 given that I have only a single profile for Thunderbird.

Additional note for anyone testing this: if an update is pending, launching from the Finder/dock will not result in the resume list being populated because the browser will be restarted at some point before becoming usable.

While this patch updates the launch code, it cannot be run on sdk versions below 10.15. In our code we still have a minimum requirement of 10.12, so to make this work we check for our sdk version using the existing @available objc call. Some changes have to be made to the way we launch to accommodate the new method, noted below.