* 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>
This ensures that we do not attempt places initialization before
Megazord.init() finishes, and that touching BrowserStore does not
kick-off places initialization (due to the `cleanup` call being a
side-effect of creating metadata middleware, used as part of the
BrowserStore).
Glean initialization happens before initialize megazord, and it touches
core.store BrowserStore instance, kicking-off places initialization on
an IO thread (due to the cleanup call), which raced megazord
initialization on the main thread.
App init sequence is a bit of a mine-field, so this patch takes the easy
way out and doesn't attempt to re-order initialization sequence. Also,
initializing places as a side-effect of touching BrowserStore was also,
clearly, a bug.
The StartupActivityStateProvider uses an imperative implementation,
driven by callbacks, to set the state of the application. This is hard
to follow as you need to understand which callbacks will be called in
which order. For example, to make sense of an implementation like this,
COLD, WARM, AND HOT would likely need to be implemented in separate
ActivityLifecycleCallbacks.
I feel the StartupStateProvider is an improvement because it leverages
the StartupActivityLog to query a linear state for a more understandable
implementation. Furthermore, it seems accessible to write COLD, WARM,
and HOT in the same class because they can all be approached the same
way.
* Add intent processor for locale changes
* Recreate notification and notify in the service
* Use locale use cases to update notification
* Use notification id instead of tag
* Add locale use cases and restore locale in application
* Send locale to service instead of string
* Controller tests for locale
* Update Android Components version to 74.0.20210323143308
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
Hopefully this will help us understand behavior of the
`application_on_create` probe, specifically that it seems to take longer
in telemetry than in does locally compared to `home_activity_on_create`
(comparing the medians to local runs)..
Only on API 23+ (minimum Android version needed for SecureAbove22Preferences)
and only if enabled by a Nimbus experiment.
The Nimbus experiment will have the key `fenix-android-keystore` and use the
default branches - "control" and "treatment".
Previously setting it might have been arbitrarily delayed, resulting in
this metrics missing from pings that get submitted earlier.
Setting it early should prevent that.
The performance impact is negligible, Glean dispatches recording that
data off-main-thread anyway.
I validated:
- that the log statement appeared in Nightly but not in Beta.
- that the local runtimes of our perftest increased (the median diff is 124ms)
* For #15278: added CoroutineManager to count runBlocking calls
* For #15278: Added actual detekt rule for runblocking and its config to the yaml
* For #15278: Added unit test for RunblockingCounter
* For #15278: renamed StrictModeStartupSuppressionCountTest.kt to PerformanceStartupTest.kt and added runBlockingCount test
* Lint fix
* For #15278: made runblocking a Long to prevent overflow
* For #15278: fixed MozRunblocking name, description and moved RunBlockingCounter to perf package
* For #15278:Renamed MozillaRunblockingCheck to MozillaRunBlockingCheck
* For #15278: Added setup for unit test, since it failed without restting counter
* For #15278: Fixed naming for RunBlocking lint check
* For #15278: removed changes made to test to use runBlockingIncrement
* For #15728: added test exclusion for runBlocking check
* For #15278: changed null check and added Synchronized to count setter
* For #15278: fix for nits
* For #15278: added StartupExcessiveResourceUseTest to CODEOWNERS
* For #15278: fixed for nits
* For #15278: Moved increment function to extension function and fixed indentation
* For #15278: Added tests for Atomic Integer extension and nit fix
* For #15929: Remove SearchWidgetCFR telemetry.
* For #15929: Remove SearchWidgetCFR and search widget experiment.
* For #15929: Remove unit tests references to search widget experiment.
In a followup PR, we need to add state to strictModeManager (the
number of suppressions). This is much simpler to do when this is defined
as a class rather than an object. However, when this is defined as a
class, `resetAfter` needs access to the strictModeManager. Instead of
passing it in as an argument, it made sense to move this function onto
the strictModeManager instead.
Since folks are used to calling:
```
StrictMode.ThreadPolicy.allowThreadDiskReads().resetAfter
```
We're going to have to add a lint check to prevent them from doing that.
I originally tried to create this PR leaving this as an object to keep
the change simple but it wasn't worth it - once the object started to
keep state, we'd need to manually reset the state between runs. Also,
the tests were already getting hacky with static mocking so it was
easier to address some of those issues this way too.
* Update Android Components version to 57.0.0.
* Remove feature flag for "View Downloads".
* Update search enginer list from changes by #13452
Co-authored-by: Chenxia Liu <liuche@mozilla.com>
* For #11660:added prefetch for topsites
TopSites will be prefetched with observerOnce (wrapper around observerForever).
Also, the SessionControlView.update() is called right away instead of waiting from consumeFrom
in the HomeFragment.onCreateView() which will allow the UI to render all at once on its first
perform traversal
* Removed the submitList(null) since it retriggered a drawing on lower end device
for #7225, refactored and cleanup the branch.
for #7225, change strict mode policy only on main process.
for #7225, setting thread policy inside a seperate thread to keep it from getting overridden in activities.
for #7225 removed Handler().postAtFrontOfQueue as a solution due to unknown side effects. moved the enableStrictMode function to be static so we can reuse it.
for #7225 lint check
for #7225 created strict mode manager and moved enabledStrictMode function inside it.
for #7225 removed penalty death on network
for #7225 added allow disk access on thread for already existing violation
strict mode running in main process to see if it passes the gitlab check, will revert it if it doesnt
allowed diskread for super.onCreate for home activity
added comments for disk violation oncreate homeactivity
added fragment manager inside strictmode manager
allowed disk read for onboarding
allowed disk read for cachedTopSites
In order to hide the time it takes for the account manager to be initialized
(which always involves disk IO, and often network IO), let's kick it off
after "visual completeness".
This makes sure that for most users, by the time they interact with the account
manager-related functionality (e.g. in Settings), it's ready to go.
Also, for signed-in users, this will establish background sync workers.
This replaces the StartupTaskManager we had with a more general class.
New implementation is a thread-safe "gated task executor", which either
runs the task right away if it's marked as 'ready', or queries it to be
executed later on.
This ability to either execute or queue a task will be useful later on in the
commit series.
In order to eat the perceived performance costs, we initialize storage
once we're visually complete. This way, we're reducing chances of user performing
a UI action which will trigger storage init and delay said action.
As far as I can tell, we never actually exercise the a-s libraries in Fenix tests currently (this was one of the presumed reasons for having a direct dependency).
In a different branch I've started work on adding end-to-end tests, but currently that's blocked on trying to figure out to load native libraries in tests (somehow, fenix's setup is different than what we have in A-C, not yet clear to me in what way).
Another reason for a direct dependency (i think) is that we needed it to configure a `fenix` megazord. This could be solved via a `support-megazord-fenix` a-c component that provides the correct transient dependencies,
but we can also just switch to use the `full` megazord instead, which is essentially what fenix megazord is at this point. A-S team wants to remove the fenix megazord, so this will help. This is what this patch does.
Noah Bond
Christian Sadilek
Arturo Mejia
Michael Comella
Elise Richards
Grisha Kruglov
Rohan Maity
Roger Yang
Sebastian Kaspari
Gabriel Luong
mcarare
Mugurell
Jan-Erik Rediger
jhugman
MarcLeclair
Mihai Adrian Carare
Sachin
Jeff Boek
Tiger Oakes
Sawyer Blatz
Mihai Branescu
Hakkı Kaan Çalışkan
ekager
Jonathan Almeida
Will Hawkins