Skip to content

Bug 41076&41077: Second version of the MB installer

Pier Angelo Vendrame requested to merge pierov/tor-browser-build:bug_41076 into main

Merge Info

Related Issues

Backporting

Timeline

  • Immediate: patchset needed as soon as possible
  • Next Minor Stable Release: patchset that needs to be verified in nightly before backport
  • Eventually: patchset that needs to be verified in alpha before backport
  • No Backport (preferred): patchset for the next major stable

(Optional) Justification

  • Emergency security update: patchset fixes CVEs, 0-days, etc
  • Censorship event: patchset enables censorship circumvention
  • Critical bug-fix: patchset fixes a bug in core-functionality
  • Consistency: patchset which would make development easier if it were in both the alpha and release branches; developer tools, build system changes, etc
  • Sponsor required: patchset required for sponsor
  • Other: please explain

Issue Tracking

Review

Request Reviewer

  • Request review from an applications developer depending on modified system:
    • NOTE: if the MR modifies multiple areas, please /cc all the relevant reviewers (since gitlab only allows 1 reviewer)
    • accessibility : henry
    • android : clairehurst, dan
    • build system : boklm
    • extensions : ma1
    • firefox internals (XUL/JS/XPCOM) : ma1
    • fonts : pierov
    • frontend (implementation) : henry
    • frontend (review) : donuts, richard
    • localization : henry, pierov
    • macos : clairehurst, dan
    • nightly builds : boklm
    • rebases/release-prep : boklm, dan, ma1, pierov, richard
    • security : ma1
    • signing : boklm, richard
    • updater : pierov
    • misc/other : pierov, richard

/cc @richard

Change Description

As per Rui's request, the installer should be quite different from what we initially drafted, so here's a second draft that will help me to work on the default browser.

Rui asked that we implemented the possibility to install MB with a single click with the default options, but also the possibility to use the same .exe for the portable install.

In the same page where you choose if you want to do the portable install, you can choose if you want the desktop icon (instead of abusing of the readme checkbox like the Tor Browser installer does).

I didn't add a checkbox for the start menu because we might have to always add one for the install (for the default browser, because it's based on the AUMID and the AUMID is tied to the start menu entry - I'm not sure you can customize it without the start menu entry). So, we always add it for the install mode, and never add it for the portable mode. We will let the designers sort this out eventually.

In general, this wasn't approved by the UX team, but it's a blocker for the default browser investigation. So, the idea is that we keep shipping the portable installer, and just keep this for testing purposes. Also, it might help shaping the final UX eventually (e.g., we might just add a few more texts, but keep this new script otherwise).

Since it isn't definitive, I didn't handle the localization yet, but after we have the final design, we should do that.

The installation is only for the current user, but I've been told it's okay. This allows us not to enable the privilege elevation code paths - I have a branch that can do it in my fork, but it isn't ready. Rui said that he talked with other Mullvad people, and they think that eventually the current-user only install could stay, as not having the privilege elevation paths enabled is positive for MB.

The main differences between the portable and install mode are:

  • install mode will always store the profile inside %appData% and %localAppData% regardless of where it's installed, following Moz's schemes to find those paths (currently, it's Mullvad\MullvadBrowser\Profiles)
  • install mode will write to the registry, so that users can uninstall the browser from there
    • for this reason, we need to write an uninstaller for install mode
    • also, after the updates we need to update the version of the browser (we don't update the date because Windows uses the date at which you modify the registry items if you don't provide an explicit date)
      • Mozilla does so with the uninstaller, but we write it from the installer. So, to be able to update the postupdate.exe hook, I created an additional NSIS executable that we include also for portable installations (and it checks whether we're in portable or install mode).
      • The post update is enabled in mullvad-browser!102 (merged).
    • another consequence is that we can have as many portable installations as we want, but only one install. So, the updater checks if there's already a registry entry for Mullvad Browser, and in case it won't prompt for the install location, and it will change the button from Install to Update. Portable install will be still possible.
      • multiple installs would be difficult to differentiate in the control panel from the UX point of view, and we'd have to deal with the install hash to identify each one - Firefox does something like this already, but it's additional complexity that we could implement in a second moment only if we really need it
      • the only exception is that understanding channels is easy enough, so actually you can have one install for each channel (one for release, one for alpha, one for nightly). Testbuilds will be displayed as testbuild, but will conflict with the channel they're based on, maybe we can change this (I've realized only now)

While the new installer is quite different from the previous one, they also share a lot of functionalities, so I've used .nsh files (NSIS Headers).

Also, to make it easier to test the changes, I removed all template directives, except for a single file, in which we convert them to NSIS defines. This allows to run the scripts in a Windows system with the NSIS GUI. It makes the process much more streamlined. Notice that a "rendered" defines.nsh is available in out/browser.

Finally, the uninstaller should remove the links it created. I thought it would have been sloppy if we just removed the link without testing if it's to the actual install we do have (rather than, for example, to a portable install). So, the uninstaller reads the link target, but to do so I had to add the ShellLink plugin.

How Tested

Built, and checked the installation phases, including trying to reinstall when an installation already exist.

Then, tried to update and check that the control panel entries are updated (it includes the commits from mullvad-browser.git).

Also, tried to uninstall.

In general, I've played with the different combinations.

For the ShellLink plugin, I've tested it builds and the NSIS artifact stays reproducible even after the changes in its build script. Then, I tested the desktop icon isn't deleted if I change its target path.

Build: https://tb-build-03.torproject.org/~pierov/mullvadbrowser/nightly/tbb-nightly.2024.01.10/mullvad-browser-windows-x86_64-install-tbb-nightly.2024.01.10.exe

Edited by Pier Angelo Vendrame

Merge request reports