* Renew product telemetry probes expiring in august 2021
* Add placeholder for data reviews
* Allow unneeded metrics to expire in August. To be re-evaluated later.
* Add link to data review
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This differs from `tab_view_setting` which tells us what the user's tab
setting is at startup. It does not tell us if the user explicitly
changed it instead of just using the default (which was recently
changed in #19809).
* Remove references to preferences.open_links_in_private and preferences.private_search_suggestions in tests. These metrics have been expired and may be removed.
* Add ignores for performance metrics that have expired.
* Remove tabs_tray.cfr.dismiss and tabs_tray.cfr.go_to_settings telemetry probes.
* Remove metrics controller from signature and remove in tests
* Renew product telemetry probes expiring in august 2021
* Add placeholder for data reviews
* Allow unneeded metrics to expire in August. To be re-evaluated later.
* Add link to data review
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This is pedantic, but strictly something called <provider-name> is considered an HTML tag
unless it's in a code block (backticks).
See mozilla/glean-dictionary#549 and mozilla/glean-dictionary#497. I'm going to fix this upstream
but figured I might as well file a PR here to fix the underlying issue.
For #18857 [Telemetry] Send a Glean event when users change their default browser
For #18855 [Telemetry] Send an event when users open the toolbar menu
For #18851 [Telemetry] Send an event when users click on the "set as default browser" entry in the toolbar menu
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.
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)..