One of the protocols that the Windows installer registers us with the OS as a handler for is ftp:, but we're dropping support for that in bug 1574475, so we should stop claiming to support it here. This means both no longer registering support for the protocol on new installs, and also removing the existing registration during updates.

The removal of support is starting by putting a pref in front of the whole feature. Currently that pref is disabled only for Nightly, and I haven't seen a timeline for letting that ride the trains (the original plan was to do that in 77 with an exception for ESR 78, but that's been delayed). Having this change landed while only Nightly is affected isn't critical, but we should definitely be ready when the pref change does start riding the trains.

For builds with ftp disabled (see below), this commit:

1. stops registering the ftp protocol handler at install time;
2. actively unregisters the ftp protocol handler at postupdate time;
3. stops unregistering the ftp protocol handler at uninstall time.

The rationale for 3) is that by the time a helper.exe with this
change is in place, the postupdate step has already run and
unregistered the ftp protocol handler. This could, of course, fail,
and a fallback would be nice. However having a guarded block, just
like everywhere else, will make it much more likely that the complete
removal of the ftp protocol will also cull the uninstall code. I
prefer making the latter cleanup more likely to be complete.

The bool pref that disables ftp functionality is
"network.ftp.enabled", and at this time that defaults to
!NIGHTLY_BUILD. In the {un}install process, there's no way to inspect
that pref dynamically, so we use !NIGHTLY_BUILD as well.

This opens a race window for developers to change the pref default
without changing the {un}install conditional at the same time. It
would be possible to close that window by introducing a new configure
subst but given the imminent removal of the ftp protocol entirely it
doesn't seem necessary.

For QA:

• Try build installer with this patch
• Try build installer without this patch

There are two things that I tested in this ticket. The test for whether Firefox is registered as an FTP protocol handler is, on Win 10, to go to "Settings > Choose a default app for each protocol" and verify if the correct Firefox is listed as an option for the ftp:// protocol. Be aware that the list needs to be refreshed manually after changes (by going to Settings and entering the section again).

1. First, that a fresh install with this patch does not register Firefox as an FTP protocol handler. To test, install the new version, and verify.

Now, copy out the new uninstall/helper.exe to a temporary location and uninstall the Firefox just installed entirely.

2. Second, test that the post-update step from a fresh install applied to an old install unregisters Firefox as an FTP protocol handler. To run the post-update step: install the old version (without); copy in the updated uninstall/helper.exe from above; then, in the uninstall directory, run helper.exe /PostUpdate.

This should succeed with both elevated and unelevated installers (providing you invoke the helper.exe with Administrator privileges).

https://hg.mozilla.org/mozilla-central/rev/741e5111fa40

I have managed to reproduce the issue on an old build Fx77.0a1 build ID: 20200413225327.
The issue is verified fixed on the latest nightly build Fx79.0a1. A new installed build is no longer listed an option for FTP protocol. That is also the case for an on build following the steps mentioned in the second part of comment 2.

Comment on attachment 9202404 [details]
Bug 1629636 - Make Windows install not register "ftp" protocol handler. r?#application-update-reviewers

Revision D104735 was moved to bug 1691951. Setting attachment 9202404 [details] to obsolete.