This problem applies also to desktop, to a certain extent.
If passing our configuration makes Tor unhappy, we give up with the initialization.
On desktop it's less problematic: the UI kinda sucks because you will get the annoying popup of initialization failed, and you might not understand it's a bridge problem.
However, you can always go to the connection settings, and drop the bridge.
It might be a problem for upgrading users, or if we will drop a PT in the future.
On the other hand, for Android it completely breaks the browser, and the settings will accept any bridge string.
Maybe we should accept a failure to push settings during the startup.
If passing our configuration makes Tor unhappy, we give up with the initialization.
I'm pretty sure this didn't use to happen on desktop with bad bridge lines (I've added a bunch before). I can't remember if tor was able to ignore the bad bridges, or whether the settings all fail with a console error but no UI feedback. Now it will kill the tor process!
It might be too late to add some decent UI. But we could not unint the TorProvider when settings fail, and just log the error to console instead. Then the user can still go through "about:torconnect" to correct the problem.
Currently the TorSettings are applied all-or-nothing. So your proxy or firewall settings will get ignored if you have a bad bridge. Maybe we should separate these out as well and treat each failure separately.
It also means that all your bridges will be ignored if you have one bad bridge, but without a reliable way to tell which bridge caused the failure it might not be feasible to try and apply the other bridges.
Yep. We didn't manage to do something for 13.5, but we should definitely do something sooner rather than later.
Probably we could delete the old Error state, but reintroduce the old FatalError state that was never used for this kind of cases (and have some UI that removes the prompt).
On Android the prompt isn't actually shown probably because the browser isn't "ready".
I had the impression that in several circumstances the prompt was ignored.
But we could not unint the TorProvider when settings fail, and just log the error to console instead. Then the user can still go through "about:torconnect" to correct the problem.
Yep, I agree. It's more or less what I meant with "accept a failure to push settings during the startup" .
Currently the TorSettings are applied all-or-nothing. So your proxy or firewall settings will get ignored if you have a bad bridge. Maybe we should separate these out as well and treat each failure separately.
Good idea, even though I think this is probably a lower priority thing and we can fix it in alpha first (whereas I'd go with the other workaround already in stable, as we need to avoid possible bad situations after the update).
Currently the TorSettings are applied all-or-nothing. So your proxy or firewall settings will get ignored if you have a bad bridge. Maybe we should separate these out as well and treat each failure separately.
@pierov regarding "SETCONF". If you pass in a bunch of settings to tor and one of them causes the command to fail, will tor still have set some of them? Or is "SETCONF" no-operation if it does not return "250 OK"? I.e. if writeSettings fails, what state is tor left in?
The workaround works, but we should find a way to pass the failure down to the Android UI (the SETCONF command when we apply fails for sure, and it's already passed down to the Java side, judging by the JS code, but probably there isn't a Java handler).