Manage the shown user stage in TorConnect module

Merge Info

Related Issues

• #41710 (closed)

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
• Localization: typos and other localization changes that should be also in the release branch
• Other: please explain

Merging

• Merge to tor-browser - !fixups to tor-browser-specific commits, new features, security backports
• Merge to base-browser - !fixups to base-browser-specific commits, new features to be shared with mullvad-browser, and security backports
  • NOTE: if your changeset includes patches to both base-browser and tor-browser please clearly label in the change description which commits should be cherry-picked to base-browser after merging

Issue Tracking

• Link resolved issues with appropriate Release Prep issue for changelog generation

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) : jwilde, ma1
  • fonts : pierov
  • frontend (implementation) : henry
  • frontend (review) : donuts, richard
  • localization : henry, pierov
  • macOS : clairehurst, dan
  • nightly builds : boklm
  • rebases/release-prep : dan, ma1, pierov, richard
  • security : jwilde, ma1
  • signing : boklm, richard
  • updater : pierov
  • windows : jwilde, richard
  • misc/other : pierov, richard

Change Description

1. Move bootstrapping attempts into a new class.

We copy the logic from "BootstrappingState" and "AutoBootstrappingState" into "BootstrappingAttempt" and "AutoBootstrappingAttempt". The main difference is that we can do the following:

bootstrapAttempt = new BootstrapAttempt();
bootstrapResult = await bootstrapAttempt.run();
// ...
bootstrapAttempt.cancel();

rather than using the "StateCallback" class, which requires some complicated state management.

Moreover, "AutoBootstrappingAttempt" will use "BootstrappingAttempt" for each of its attempts. So the logic for bootstrapping can be kept in one place.

Some other changes:

1. Censorship simulation will no longer necessarily avoid the Moat calls, so these can be tested.
2. It would be possible to perform the internet test when auto-bootstrapping as well.
3. When auto-bootstrapping, if "Bootstrapping" produces an error other than a "BootstrapError", we can end it early.
4. No longer set TorConnect internals.
5. More fine-grained control over censorship simulation and offline simulation.

2. Drop StateCallback from TorConnect.

Instead of managing the abstract "State" we directly manager the user "Stage". We provide backward compatibility with the "State" for android and about:torconnect. Eventually this logic can be dropped from these endpoints and they can listen for changes in the "Stage" instead.

The behaviour for about:torconnect is mostly the same as before, with some exceptions:

1. If the user sees the "Offline" state, and starts and cancels the bootstrap, they should return the to the "Offline" state, rather than "ConnectToTor".
2. Trying to start a bootstrap via the UI before the settings have loaded will do nothing.
3. Pressing a breadcrumb whilst bootstrapping will now also cancel the bootstrap.

3. Switch about:torconnect to use TorConnect.stage to control

the shown stage and sync pages.

Now TorConnect entirely controls which stage should be shown to the user, and "about:torconnect" simply relays the user actions up to TorConnect to handle. In particular, we stop sending out "torconnect:broadcast-user-action" to sync pages.

We also do not try and sync the selected region between pages. However all pages should still show the actually submitted region after a bootstrap fails. E.g. to confirm their location.

We also allow the user to re-select "Automatic" when they use breadcrumbs to go back a stage.

How Tested