Bump top site limit under its new name
Fix unresilved conflict
Allow Nimbus to generate code that allows the fork flavors
Drop private browsing page again
Use the new text color name
Point at paged style again
Bring back Sentry so we don't have to change the code that would call it
Note we need to build with app: now for some reason
Also prefix Github build commands
Adapt to settings moving
Parse Iceraven versions
Discover the linter's formatter
Get rid of some Detekt complaints
Handle more weird version strings
Finish README
Stop auto-release changelogs from being too huge
Fix#440 by reattaching settings
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.
* For #21903 - Added telemetry for interacting with inactive tabs
* For #21903 - Added missing inactive tab delete count event to delete all event
* For #21903 - Added PR numbers to metrics
* For #21903 - Updated broken unit tests. Resolved critical lint warning.
* For #21903 - Fixed inactive tabs setting toggle metric
* For #21903 - Updated FenixApp unit test
* For #21903 - Updated newline character in Metrics. Set inactive tab metrics' lifetime to default. Updated expiration to Nov 2022. Refactored inactive tabs metric to be a single metric.
* PR: addendum for last commit that missed a file
* For #21903 - Changed logic check for reporting inactive tab count
* PR: fixed merge conflict
* For #21903 - Removed tab close tracking when the user closes ALL inactive tabs
* For #21903 - Removed individual tab close metric verify from CLOSE ALL test
* For #21903 - Updated inactive tabs toggle setting expiration to match the expiration of the other events
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Adam Novak
Jonathan Almeida
mcarare
Alexandru2909
Mugurell
MatthewTighe
Noah Bond
Jan-Erik Rediger
Gabriel Luong
Alexandru2909
Ben Dean-Kawamura
jhugman
Arturo Mejia
Brais Gabín
Noah Bond
Roger Yang
Michael Comella
Christian Sadilek