TorConnect might restore old settings that were changed from the preferences
In TorConnect we get a copy of the original settings (this.originalSettings = TorSettings.getSettings();
) only once before trying all the settings we've received from Moat (and we bootstrap for each settings set, so the browser might take a long time to do stuff).
If the user changes settings, and we failed to bootstrap, we restore the settings we had before, which might be surprising.
So, we should check if the settings we're about to overwrite when we restore the old settings.
As a sequence of events:
- TorConnect backup configuration A before contacting Moat
- TorConnect sets the config B it received from Moat
- While the bootstrap is happening, the user changes settings, producing config C
- The boostrap fails: TorConnect restores config A!
Also, since we might receive many configuration sets, we might also apply config D, E, F and so on and possibly replace settings from configuration C.
On Android this cannot happen because going to settings stops the bootstrap, and we intend to keep this behavior at least for starters, when implementing the connection assist there.
However, on desktop is more difficult, because we have tabs. Therefore, we might do something else, e.g., disable all the settings while we're bootstrapping, and display a message bar telling something like "The bootstrap is going on. Cancel it to unlock the settings".
Design estimate:
- Complexity: medium (3 days)
- Figure out the appropriate solution. Should we prevent people from accessing the Settings on desktop just like on Android? Or do we create a warning for people that their settings might be overwritten?
- Create designs that solve the issue.
- Uncertainty level: moderate (1.5)
- I imagine trying to figure out which solution we should apply and how we apply it can take time.
- Total: 3-4.5 days