Bug 41907: Change TorConnect state after the process becomes ready only when we are in the initial state.

Merge Info

Related Issues

• #41907 (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
• 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 : dan
  • build system : boklm
  • extensions : ma1
  • firefox internals (XUL/JS/XPCOM) : ma1
  • fonts : pierov
  • frontend (implementation) : henry
  • frontend (review) : donuts, richard
  • localization : henry, pierov
  • nightly builds : boklm
  • rebases/release-prep : dan_b, ma1, pierov, richard
  • security : ma1
  • signing : boklm, richard
  • updater : pierov
  • misc/other : pierov, richard

Change Description

I decided to investigate on a bug we've had for a long time.

The bootstrap is interrupted (especially on Windows, but I use a VM) without any explanation.

The issue is that TorConnect might receive a notification when its state has already changed from the initial one. In particular, if it goes from Bootstrapping to Configuring, it also makes the bootstrap stop (set DisableNetwork=1).

My solution is to ignore this notification if we aren't in the initial state anymore.

A consideration to do is that the settings topic we're ignoring is notified when we've set the configuration from browser preferences to torrc. However, the settings from the previous session should already be in the torrc, and any other change should have already been saved, and I don't think we need to cycle a disable network to apply them in any case.

The alternative is to rework the UX, but I don't think it's really needed in this case.

See also my comments on the related issue.

Since this bug is only a bit annoying, I think it's fine to keep it in alpha for a while, especially since we're not doing many of them, without backporting it.

requested review from @richard

assigned to @pierov

changed title from Bug 41907: Change state after the process becomes ready only when we are in the initial state. to Bug 41907: Change TorConnect state after the process becomes ready only when we are in the initial state.

added 79 commits

• 0c41e144...bdda467f - 78 commits from branch tpo/applications:tor-browser-115.1.0esr-13.0-1
• 142d3381 - fixup! Bug 40597: Implement TorSettings module

Compare with previous version

marked this merge request as draft from pierov/tor-browser@142d3381

marked this merge request as ready

Ok we had a big discussion on this on IRC.

The fundamental issue this MR works around is that UI elements for bootstrapping are available before the tor controller says 'yep tor is ready to go!'. As a result, when the user presses the connect button, the bootstrap command is sent to controller, which sends it as soon as the tor controller connection is ready. Then the TorSettings module notifies everyone that the tor dameon is ready which pushes TorConnect out of the 'Initial' state into 'Configuring'. Normally going into 'Configuring' happens from 'Bootstrapping' so DisableNetwork=1 is set in the tor daemon (which stops the current bootstrap attempt).

What the user sees is they press Connect, bootstrapping starts, and then it stops for no reason without their intervention, and so have to press connect again.

Video: 2023-07-27_19-08-27.mkv

Long term, ALL UX elements need to be disabled by default and check the future TorProvider to see if it's ready before enabling (and if not, wait for some global observer event before enabling). This will prevent these types of race-conditions.

added 1 commit

• 8d6ae7d7 - fixup! Bug 40597: Implement TorSettings module

Compare with previous version

marked this merge request as draft from pierov/tor-browser@8d6ae7d7

marked this merge request as ready

resolved all threads

approved this merge request

added 8 commits

• 8d6ae7d7...1a8be7b1 - 7 commits from branch tpo/applications:tor-browser-115.1.0esr-13.0-1
• f0493f9f - fixup! Bug 40597: Implement TorSettings module

Compare with previous version

marked this merge request as draft from pierov/tor-browser@f0493f9f

marked this merge request as ready

merged