Bug 41114: Fix no-async-promise-executor on TorConnect and general refactor
Loading
tor-browser
- !fixups
to tor-browser
-specific commits, new features, security backportsbase-browser
- !fixups
to base-browser
-specific commits, new features to be shared with mullvad-browser
, and security backports
base-browser
and tor-browser
please clearly label in the change description which commits should be cherry-picked to base-browser
after merging/cc
all the relevant reviewers (since gitlab only allows 1 reviewer)TorConnect used to have many async promise executor, which are a problem because under some cirumstances the exceptions might be lost.
After starting to remove the async executors, I noticed they were not really needed, since for most of the time they were used only to make sure we blocked the transition to the next state until actually needed. Also, the promised were resolved in a cleanup function created only for this purpose in most of all occurrences. In many cases, the state callback does not even need to be async. So, I thought I could shift the waiting from the function that started the state callback to the function that actually performs the state change.
Also, to simplify the code (at least remove a lot of indentation levels), I switched the states from being functions to actual ES
classes.
We used to create a companion object (this._context
) in any case, and for this reason we had to use the function keyword instead of arrow functions.
Therefore, I thought of replacing it with explicitly being OOP.
For the reviewer(s): please go through every commit! The general review will basically be the whole file rewritten. The second, third and last commit, in particular, are trivial to review only if you do something special:
git show --color-moved
. It will show the actual changes are just a fewI went commit by commit and tested that: