richard pushed to branch firefox-android-115.2.1-13.5-1 at The Tor Project / Applications / firefox-android
Commits: 1cf0ae40 by Dan Ballard at 2024-06-07T11:08:19-07:00 fixup! Add Tor integration and UI
Bug 42593: Also persisting of bridges set to off, support enabling bridges once a previous selection is remembered
- - - - -
2 changed files:
- fenix/app/src/main/java/org/mozilla/fenix/settings/TorBridgeConfigFragment.kt - fenix/app/src/main/java/org/mozilla/fenix/tor/TorControllerGV.kt
Changes:
===================================== fenix/app/src/main/java/org/mozilla/fenix/settings/TorBridgeConfigFragment.kt ===================================== @@ -103,7 +103,7 @@ class TorBridgeConfigFragment : PreferenceFragmentCompat() { preference.context.components.torController.bridgeTransport = bridge previousTransportConfig = bridge updateCurrentConfiguredBridgePref(preference) - context.components.torController.restartTor() + preference.context.components.torController.restartTor() } true }
===================================== fenix/app/src/main/java/org/mozilla/fenix/tor/TorControllerGV.kt ===================================== @@ -89,13 +89,13 @@ class TorControllerGV( }
- // Bridges Enabled is a cache variable. The TorController interface we are locked into at the - // moment to support the TAS backend calls setting `bridgesEnabled = true` and setting - // the bridge type seperately so to support that, - // while at the same time it being invalid states to not submit them together to the TorSettings - // backend where TorSettings.sys.mjs's #cleanupSettings will remove a lone bridgeEnabled - // we thus have to hold it here to support the UI but not submit to the backend until - // bridgeTransport is also set (below) + // On a fresh install bridgeEnagled can be set to true without a valid bridgeSource + // having been selected. After first use this will not happen because last selected bridge + // will be remembered and reused. + // However, on first use, submitting this to TorSettings is an invalid state. + // TorSettings.sys.mjs's #cleanupSettings will remove a lone bridgeEnabled with no source + // selected. Therefore we check and don't call setSettings if bridgeSource isn't selected + // (when trying to enable). Disabeling is always valid. private var _bridgesEnabled: Boolean? = null override var bridgesEnabled: Boolean get() { @@ -103,6 +103,12 @@ class TorControllerGV( } set(value) { _bridgesEnabled = value + getTorSettings()?.let { + if (!value || it.bridgesSource != BridgeSource.Invalid) { + it.bridgesEnabled = value + getTorIntegration().setSettings(it, true, true) + } + } }
@@ -146,8 +152,9 @@ class TorControllerGV(
// Currently the UI takes a user provided string and sets this in one step so there is where we - // actually set it.bridgesSource = BridgeSource.UserProvided, not above, as TorSettings.sys.mjs #cleanupSettings - // could reject BridgeSource.UserProvided with no bridge strings + // actually set it.bridgesSource = BridgeSource.UserProvided, not above, + // as TorSettings.sys.mjs #cleanupSettings could reject BridgeSource.UserProvided + // with no bridge strings override var userProvidedBridges: String? get() { return getTorSettings()?.bridgeBridgeStrings?.joinToString("\r\n")
View it on GitLab: https://gitlab.torproject.org/tpo/applications/firefox-android/-/commit/1cf0...