Review the Tor Check Service UX
While refactoring Torbutton, I found the check service, and I'm very confused by it.
I understand its intention, but I'm not sure it's something we should keep.
This check is invoked every time
about:tor is shown (instead of being called for example after the bootstrap, or when certain events happen).
The local check is usually preferred: it uses the control port to get the SOCKS ports address(es), and checks that Firefox is set to use it (/one of them if more than one).
When that isn't possible, we run a remote check: a network request to
https://check.torproject.org/?TorButton=true starts, and the browser looks for a certain string (notice that the check URL can be customized - which doesn't make much sense, for me).
The remote check is done whenever Tor Browser is set to use transparent proxy, or doesn't have a control port connection.
It's the case of Tails (but I think they disable the test or don't even use
about:tor) and Whonix (which also doesn't use
In both cases, this involves some kind of networking (on the control port when the test local), and it's an
await for it to return, and this delays the rendering of
Normally, the local test check is chosen and this delay isn't visible (unless things go wrong, like it happened with #41532 (closed), in which
about:tor was never shown because the test never ended!).
I'm not sure for the remote case, it will probably add some delay.
If we don't wait, for the current logic, if the test hasn't run yet, we'll show the "it's all good" window. And it might become suddenly the red screen of death, without user understanding why it switches from purple to red.
Also, when the test fails, it focuses the now red
about:tor tab, or it opens a new tab and focuses it.
And the test is run every time
about:tor is shown, which is bad for the delay. We could at least avoid waiting it if it failed before.
Finally, the failure condition isn't triggered when
tor dies. Only the message box is shown.