Firefox Core Engineering/App Installer roadmap

The Firefox Core Engineering (FCE) team ran from March 2016 through January 2018. All work on that team has been dispersed to other teams.

This page should be considered legacy.

For more information on previously-FCE activities, go by individuals listed in Historical knowledge areas. (If you're in a pinch, ask ddurst.)

The Firefox installers should get a user running Firefox as quickly and reliably as possible, while taking all necessary steps to make Firefox an integrated part of the system. Being a part of the user onboarding process, they should fit into the larger goals and strategy of user onboarding however possible.

Stub Installer

The stub installer provides a frictionless, streamlined installation experience with minimal user interaction, and it always installs the Firefox version that's current when you run it. The stub is intended to be the default installer and should serve the needs of the vast majority of users, without compromising the streamlined experience.

Full Installer

The full installer offers more control over installation parameters, works without needing an Internet connection, and is guaranteed to always install one particular version of Firefox. The full installer is intended to serve advanced use cases which fall outside the scope of the stub.

• Regularly measure the performance and effectiveness of the installer(s)
• Make changes as deemed necessary stemming from analysis or onboarding

A note on installer technology

Currently we offer installers only for Windows. It turns out that the best way to meet the installer's goals on other platforms is to provide the application as a package in a platform-specific format, rather than as an installer; it's the best way to be a good citizen on those platforms. This doesn't seem likely to change over the near or medium term, so the plan is to continue providing installers only for Windows.

However, there are two potential high-level avenues of future development for the installer:

1. Continue maintaining and improving the NSIS installers. Although NSIS is a rather old and fairly crufty technology at this point, it shows no signs of losing continued support. It should be possible, at least in theory, to remedy most of the downsides of the current installers within NSIS. But we won't be able to fully remedy the enterprise deployment situation, and for the others, generally speaking doing anything in NSIS is harder than it needs to be.
2. Switch over to a different installer technology. Most other systems have the same downsides that we would be trying to escape by dropping NSIS, so this really means moving to MSI and specifically to WIX. This should make huge amounts of our installer code unnecessary, since most installation logic is provided by the service. However we would need to address how to handle updates, since MSI typically expects to be the one installing patches.

• Validate that the stub installer always installs the Firefox version that's current when you run it. in progress: 1375508
• Investigate telemetry options.
• Improve speed of ... everything we can.
• Make the installer smarter and more resilient when it comes to failures.
• Integrate Full installer UX with onboarding intent.

• Implement download resume in the stub installer (798005). This is something that we already have reason to believe would lead to more successful installs and doesn't seem like a high degree of difficulty (the download process is mostly done in native code, not NSIS scripts).
• Investigate creating an automated installer test suite. This may not be possible, but it would be so helpful that it justifies going to great lengths to make it happen.
• Decide on a course for MSI/GPO support.