Unify the TCP feature with the TCP setting allowing both to be controlled
through the same Nimbus experiment.
Allow changing the default cookie policy to TCP based on the Nimbus experiment.
- Created a new "sync debug" pref screen to hold the Fxa, Sync, and Push
server override prefs. They were taking a lot of screen space on the
top-level settings menu as individual items
- Added button on that screen to quit FF which is needed to apply the
changes.
- This is definitely not the nicest UI, but hopefully QA can just
override the prefs once save them in an emulator and never have to
go back to this screen.
- I do think this is a nicer UI than before, where FF would quit
after a change to any of the prefs. That forces you to restart FF
3 times if you wanted to override all 3 server URLs.
If Total Cookie Protection is enabled when first accessing a normal tab
(not a custom tab) a new Contextual Feature Recommendation popup will be shown
informing about the added protection and allowing the user to open a support
page with more data about the new option for privacy protection.
There are three issues here that we have uncovered while investigating
this bug:
1. Settings.kt has a lazy block around `enabledTotalCookieProtection`
which ends up caching the first result it evaluates.
3. The `FeatureHolder` within FxNimbus caches the incorrectly
evaluated value and returns this value hence forth.
4. Nimbus is not ready to return a result for an engine experiment
when we need it early on in the dependency tree initialization.
There are multiple systems that require engine to be initialized for
them to work (e.g. Glean, Profiler, concept-fetch). In our TCP,
experiment, we need to apply these engine settings during the engine
initialization. So when we try and evaluate Nimbus that early on, it
has not had time to initialize itself correctly or even use the
engine's concept-fetch client to return the correct experiment result.
This bug is made worse because of the first two caching bugs where we
are always holding onto a cached value of the wrong result.
Our temporary solution is to:
1. Remove the `lazy` around `Settings.enabledTotalCookieProtection`.
2. Set the `FxNimbus.api` value right after we are done initializing
`FxNimbus` and `NimbusApi` so that all future queries to FxNimbus
will be made against a real instance of `NimbusApi`. This is a
short-term fix for the `FeatureHolder` caching bug.
3. Set a new TrackingProtectionPolicy that will evaluate Nimbus now
that it is in the correct state when receive the
`NimbusInterface.Observer.onUpdatesApplied`.
Co-authored-by: jhugman <jhugman@users.noreply.github.com>
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
