Re-enable storage maintenance call by introducing WorkManager worker on A-C side and consuming it from Fenix.
The work request is periodic and the repeat interval is 24h. It requires the device to be idle and not to have
low battery. This feature is available only for Nightly for now.
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>
This replaces the default implementation from Android-Components to add the
functionality to first navigate to the browser fragment before responding to
service workers' requests of opening new tabs.
This will register itself when the main activity is created and unregister
itself when that activity is destroyed to support requests even when the
activity is in background but prevent any leaks.
This completes the work for removing the Fennec migration support.
Before that, for Fenix release and beta, apps to which users might update to
from old Fennec builds the Glean initialization was done separately in
MigratingFenixApplication to allow time to first migrate user's telemetry
setting.
With the removal of the migration support it is now safe to initialize Glean in
the same way for all builds and remove that Fennec check.
Use the new `ServiceWorkerSupport` AC components for this.
Had to be installed in `FenixApplication` since there is a circular dependency
between the initialization of the required engine the `tabsUseCases` arguments.
* Consume Nimbus FML plugin
* Convert Homescreen to use FML
* Convert nimbusValidation to use FML
* Convert legacy experiments to use the feature API and FML
Remove dead helper code and documentation
* Fixup failing test
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Setting this value in FenixApplication.onCreate was buggy because of a race
with restoring BrowserState.
Setting it here would ensure a better granularity of the events and so to more
accurate reporting.
* For #22145 - Added telemetry to the opening screen preference.
* For #22145 - Added PR number to metric
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This allows querying from all throughout the app which of the current tabs are
inactive while taking into consideration whether the feature is enabled or not
such that when the feature is disabled it will always return an empty result.
A quantity probe in the metrics ping means we'll loose the granularity events
provided but it will be easier to extract the values.
For reporting whether the inactive tabs feature is enabled or not we already
have the "preferences.inactive_tabs_enabled" probe so I didn't duplicate this.