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)..
While we could easily move this into the metrics ping, it's better to
leave it in the other ping because it's less work and because (I think)
we'll be better able to match `framework_secondary` values to the clock
ticks if we combine them in the same ping.
We do this in order to make it easier to analyze in GLAM: see the metric
descriptions for more details.
Additionally, we change the time unit to milliseconds to make it easier
to analyze in GLAM.
* For #17418 - Adds channel "ts" to TrackKey
This is used to track if the `InContentTelemetry` is a result of the user using the Google Top Site. It looks for `&channel=ts` within the uri.
* For #17418 - Adds TopSite PerformedSearch back in
* For #17418 - Check now looks for equality with GOOGLE_URL
* For #17418 - Adds test for topSite changes
* For #11580 - Tracks text selection context menu usage
Tracks Copy, Search, Select All and Share items from the text selection context menu. Uses AC's DefaultSelectionActionDelegate to achieve this.
Co-authored-by: Gabriel Luong <gabriel.luong@gmail.com>
These pings were implemented first as counters.
When changing to events "send_in_pings: - metrics" still remained causing
confusion.
This patch comes to remove this confusion and potential future issues.
These pings were implemented first as counters.
When changing to events "send_in_pings: - metrics" still remained causing
confusion.
This patch comes to remove this confusion and potential future issues.
Adds a counter for how many times the user does the following action:
- opens the Downloads section inside the app
- tap to open an item from inside Downloads / from the download dialog
- tap to delete one or more downloads at once
* For #15929: Remove SearchWidgetCFR telemetry.
* For #15929: Remove SearchWidgetCFR and search widget experiment.
* For #15929: Remove unit tests references to search widget experiment.
* Add PWA events to metrics.
Track events for add to homescreen and install.
Map PWA facts to events
* Map component facts to local metrics
Add events pings to fragments
Supress long method for events
Move install event to AC and collect facts
Retrieve fg and bg events from Facts. Do not track intent fg/bg events, only views
* Allow onPause in base fragment to send telemetry for PWA in the external app fragment. Track foreground and bg locally in fenix, and route install and home screen taps from AC facts
* Rebase
lint check
renamed the intentReceived telemetry to appOpenedAllSource
added comments
removed unused code
moved lifecycle process to AppAllSourceStartTelemetry
moved tracking event out of init function
lint fix
moved appAllStartTelemetry to components
added bit more info about the metrics
added the onReceivedIntent metric back
minor fix
change discriptions based on the comments frm MR
wrote test cases for AppAllSourceStartTelemetry.kt
lint fix
test case to mock application going background
post rebase:
post rebase:
fixed nit from comments
fixed nit from comments
fixed nit from comments
lint fix
lint fix
* Extract controller into it's own class. Implement find dupes and filter based on username.
Create edit login controller. Add text watchers and check for duplicates.
Edit controller test
* Find duplicates and save to store
* Retrieve duplicates from AC and check list on username text changed
Move duplicates logic into the controller
* Add glean pings for delete and edit. Move logic for login manipulation into the datastore.
* Use correct threads in controller. Enable save button when applicable.
Save enabled in datastore.
Move login data to datastore
Rebase with password error states
Update metrics to be more specific for edit
* Create logins controller for AC calls
* Interactor and controller methods for edit login. Add edit view to separate out some layout manipulation.
Inflate view in edit fragment. Double layout showing up.
Edit view
Controller tests
Controller tests passing
Interactor tests
Lint and detekt cleanup
* Remove datastore and use storage controller for all logins calls to password storage.
Addressed comments
Lint
:
Rebase - 1
* for #11830 added new metric for collecting startup method
move all source startup telemetry into its own logic and added an UNKOWN state
* switched back to onNewIntent solution
* renamed the metric
As per documentation, this ping is intended to provide metrics that are managed by the library itself, and not explicitly set by the application or included in the application's metrics.yaml file.
total_uri_count continues to accurately track the URLs visited by the user in
the current session.
Websites can though programmatically redirect users to a new URL using simple
javascript even without user interaction.
This needs to be documented for future references.
We primarily want to determine if this is a problem area for us to
investigate rather than a long term measurement to keep so we should set
the expiration date accordingly. Furthermore, this code executes before
crash reporting is init so it's ideal to remove it sooner rather than
later.