Firefox is currently only offered on MacOS X as a .dmg file which is the equivalent of a compressed archive file on that platform. We run into problems with that format: * it ties our hands for what we can present to the user as the installed application and requires them to do the work of copying the app to the correct location on their system, something they will select arbitrarily * we cannot display a EULA to them and ask them to agree/disagree, then react accordingly * an installer-based app vehicle for mac will allow people to select extra components that they want / deselect extra components they don't want A hope exists in the mpkg format which is what Apple uses for their Xcode distribution. This appears on the Xcode CD as a .mpkg file. Their developer.mpkg file provides an installation wizard that walks through installing the app, first by explaining (in simple terms) the process, then by presenting a EULA, then by copying files. We probably need a similar solution to round out our story on MacOS X.

Wow, this is a massive about-face. 6 months ago, and even when I discussed with Ben a few weeks ago, drag-n-drop install was the gold standard; it's recommended by the OSX developer guide also.

you can show an eula on a disk image and drag&drop installs are still the gold standard. the user is free to put the app anywhere they want. we should have no restrictions on that.

(In reply to comment #2) > you can show an eula on a disk image and drag&drop installs are still the gold > standard. the user is free to put the app anywhere they want. we should have no > restrictions on that. Installers on Windows and the Xcode example I provided allow installing anywhere. This just lets us know where we've installed. Other things that hurt now: * We may need to be creating other ways to invoke the app like "Profile Manager" * App update band-aids on Windows download the 4-5 MB file while having the user wait for the download to complete. To avoid a significant black eye of forcing them to endure the download a second time if the user cancels during the installer, we copy the installer to the desktop in the hope that they can run it if they need to without needing to download again. On Mac, we should provide a similar solution in the meantime but where do we put the dmg so that if the copy is cancelled or the update otherwise stopped, the user doesn't have to endure the 4-5 MB download all over again? If we place the dmg on the desktop (aiming for an obvious place), how do we direct people to replace their old installation with the contents of the dmg? The fear is that the user will end up with competing installations and will bounce freely between them based on which side of the bed they awoke. This may be a WONTFIX, but if it is I want us to mark it as such knowing we can do everything we want using dmgs and dmgs alone. Otherwise, this is worth considering.

> * We may need to be creating other ways to invoke the app like "Profile > Manager" Not for users. They should be able to option-click to get safe mode (I own that bug), but we should not be messing with the ordinary structure of a mac app. And an installer doesn't solve that problem anyway. > If we place the dmg on the desktop (aiming for an obvious place), how do > we direct people to replace their old installation with the contents of Maybe we should fix the root problem by having xpinstall cache the XPI, instead of majorly changing stuff. Putting a DMG or an installer in the auto-update XPI is silly, we should work towards real install XPIs.

(In reply to comment #4) > Putting a DMG or an installer in the auto-update XPI > is silly, Do not dismiss off-hand what we're using and what works *today*. It's the one solution we have. I am all ears for a proposal to upgrade 1.0 - 1.0.2 users that let's us forget we ever did XPI-wrapped installers. > we should work towards real install XPIs. Agreed.

I believe this is now tracked in Bug 516362, let me know if it's inappropriate to close this issue — still somewhat new to Bugzilla culture. ;) The reasons are a bit different from what's stated in this bug, but the end-result should be the same.