1872934 - [meta] Support `--first-startup` on macOS

Status: NEW

(Toolkit :: General, enhancement)

Description

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

Right now, we don't run any first run/first startup experiments on macOS; that mechanism is Windows-only. See https://firefox-source-docs.mozilla.org/toolkit/modules/toolkit_modules/FirstStartup.html. The reason is because on Windows there's a hand-off between the installer and Firefox proper that "masks" the time it takes to fetch first run experiments: by closing the installer only when Firefox is ready to paint, we make it seem like the installer is slow and not Firefox itself. On macOS, there's no installer and therefore no opportunity to "mask" in this way.

This meta ticket tracks a number of enhancements:

1. Adding a postinstall script to our PKG installer
2. Making that script launch Firefox with --first-startup
3. Coordinating a channel so that the PKG install app doesn't exit until Firefox has painted
4. Improving the PKG installer experience: refreshed branding, etc
5. Putting the PKG installer into our DMG container (to maintain any attribution added to the DMG, etc)

Comment 1

[Stephen A Pohl [:spohl] (OOO until 2/27)]

Is the idea here that we make the switch to a pkg installer for ALL installs? Or only a subset that is used for experiments? I seem to recall that there were a million and one reasons why we never wanted to switch to a pkg installer for typical installs.

Comment 2

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

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

Is the idea here that we make the switch to a pkg installer for ALL installs? Or only a subset that is used for experiments? I seem to recall that there were a million and one reasons why we never wanted to switch to a pkg installer for typical installs.

Glad I CCed you! I'm starting from a place of, "hey, here's a technical path to support first run experiments, a Thing We Would Like", which naturally leads to "everybody installs from a PKG supporting this technical path". But I don't know all of the pros and cons of switching to a PKG installer and I'd like to collect them and determine if doing this is, overall, not wise. Do you know of such a list, or tickets that would need to be addressed?

Comment 3

[Stephen A Pohl [:spohl] (OOO until 2/27)]

It has been a while since I've been on the app update team myself, and while I could try to remember all the various reasons, there might be someone who can simply point us at an updated document. I'll n-i Robin and Mike who might be more up to date on this. Failing this, I'll try to dig up the reasons that we've discussed in the past.

Comment 4

[Mike Kaply [:mkaply]]

I don't have any new info. I don't know why we picked DMG over PKG in the past, but when I looked into it, in the market, it seemed pretty evenly distributed DMG vs. PKG.

PKG definitely gives us a lot more abilities during the install.

Comment 5

[Robin Steuber (she/her) [:bytesized]]

I'm afraid that I don't know of any such document. The only reason that I know of to prefer DMG over PKG at the moment is that, IICR, the PKG sets the permissions on the installation directory in such a way that application update always fails on the first try and requires that the elevation dialog be displayed and accepted in order to update. Currently, this only happens for our DMG installs if one user installs and another user tries to update. I would swear that there is a bug on file for this, but I can't seem to find it.

Presumably this issue, if it persists, could be fixed though.

Comment 6

[Mike Kaply [:mkaply]]

There was a lot of discussion of this on the Mac Admins Slack. Here's an example comment (similar to what Robin pointed out:

Q: I'd like to manage Firefox updates, I see I can enforce auto-update to be "on" using a configuration profile. Is there a deployment method I can use to ensure that Firefox won't prompt for administrator credentials for updates? Does installing via the PKG (https://download.mozilla.org/?product=firefox-pkg-latest-ssl&os=osx&lang=en-US) prevent the need for end users to enter admin creds for regular updates?

A: Nope

The only way to ensure the user can update it themselves is to ensure the app bundle is owned by that same user. That's often difficult to do in an enterprise/organizational environment.

When a user installs an app themselves by dragging it from a disk image to /Applications: 1) They are generally admin, and 2) The dragged app is now owned by that user

If Firefox is installed via package or by a software management system, the app bundle is generally owned by root.

Our strategy is to keep Firefox up-to-date using the same software management system that installed it (in this case, Munki).

Comment 7

[Mike Kaply [:mkaply]]

Other post about advantages of PKG (at least in an enterprise environment)

Is there any advantage to using a PKG installer versus DMG from an enterprise perspective? Like can the elevation entitlement be done better?

Yes, there are several advantages (or at least differences)

A package can install items with specific owner, group and mode, and does so as root.

When a user drags-and-drops from a dmg, the owner is the user, so anything that needs to have a specific owner or group --won't.

If the user installs your app via dragging-and-dropping from a disk image and you need privileged helpers, now you have to write code that runs at app launch that prompt the user for admin credentials, elevates its access, and installs the privileged helpers (or repairs their owner/group/mode).

If the user installs your software via an installer package, the privilege escalation happens at install time and the files are installed with correct owner, group, and mode. No need for you to write extra "install/repair" code.

The only "downside" I can think of is that if the app bundle is now owner by root instead of a local user, updating that app bundle must now be done either by a root process, or the user must be prompted for admin credentials. With an app that is dragged-and-dropped into place, that app bundle is now owned by that user, and a user process can update the app bundle without additional privileges

IMHO, except for the simplest, self-contained apps, pkg > dmg

I have folks we can have a deeper discussion about this with if we want.

Comment 8

[Mike Kaply [:mkaply]]

Also related, we'll need to have a way to turn this off for enterprise. Apps get installed without the user being involved and sometimes without a user logged in at all, so Firefox can't /shouldn't be launched in those cases.

Comment 9

[Mike Kaply [:mkaply]]

FYI, you can detect command line installs:

ENVIRONMENT
COMMAND_LINE_INSTALL Set when performing an installation using the installer command.

Comment 10

[Stephen A Pohl [:spohl] (OOO until 2/27)]

I can at least remember two reasons to prefer the drag-and-drop DMG installs over .pkg:

1. Prior to the App Store, drag-and-drop installs were the typical way of installing apps on macOS (or rather, OS X).
2. .pkg requires several clicks to complete the install. Every click was expected to see a certain percentage of users dropping out of the install process.

I want to emphasize that I'm not advocating for drag-and-drop installs necessarily, but having seen as much pushback in the past I want us to be sure that we're going into this with our eyes wide open. :rstrong used to be a great resource for the history behind these thing.

Comment 11

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

Thanks, all, for this helpful discussion. Most of these things I was already aware of, but great to collect them!

Re: password prompts, there's a long-running issue with the group: see https://bugzilla.mozilla.org/show_bug.cgi?id=1812480. In extremis, this could be fixed in a postinstall script. This is likely what Robin refers to in https://bugzilla.mozilla.org/show_bug.cgi?id=1872934#c5. If we can't avoid the initial prompt for Administrator credentials, that sounds like a pretty hard blocker -- we don't want to regress that flow.

Open question: would we want to support installing for everybody and also installing only for me? More options (more clicks) lose more users, and almost all users will be better off with /Applications/Firefox.app, but worth discussing. Thoughts?

Comment 12

[Haik Aftandilian [:haik]]

This won't affect most users, but another issue with our .pkg is that for Beta we use the same bundle ID as Release. We intentionally use the same bundle ID so that Beta release candidates are very similar to Release builds for validation. But as a result, if you have Release installed and run the Beta .pkg installer, the Release install will be overwritten. The algorithm used by macOS to choose the installation location includes matching a bundle ID and overwriting. And after installation, it's not clear where Firefox has been installed unless you view the log during installation. With Nightly, which gets its own bundle ID, the installer can choose to overwrite testing versions (you may have in your developer repo for example) instead of the version in /Applications. These issues are probably addressable, but they need some work as it stands.

Comment 13

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

Attachment: WIP: Bug 1872934 - DO NOT LAND - WIP hacking in a PKG postinstall script.