Add browser.urlbar.onEngagement WebExtensions API
Categories
(Firefox :: Address Bar, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: adw, Assigned: adw)
References
Details
Attachments
(1 file, 1 obsolete file)
Marco and I discussed this today. Here's my proposal.
For the interventions experiment, we need to record the types of interventions the user sees and picks. Specifically, we want to record the types for each engagement they have with the urlbar. The types are determined by the experiment extension. We already have engagement event telemetry in the urlbar, so it would be nice if the extension could augment it.
This adds a details key to the event telemetry extra. It's an unstructured string we can use for whatever purpose we need. It's easy to imagine using it in future experiments to augment telemetry events with additional relevant info. I added a webext API to let extensions set and get it.
I know we can also register event telemetry at runtime. But we already have this built-in event telemetry, and analysis and the implementation are easier if we could just augment it. As an alternative, browser.urlbar could have onEngagementStart and onEngagementEnd events that the extension would listen for, and then it would record its own parallel event telemetry.
|
Assignee | |
Comment 1•5 years ago
|
||
Marco and I discussed this today. Here's my proposal.
For the interventions experiment, we need to record the types of interventions the user sees and picks. Specifically, we want to record the types for each engagement they have with the urlbar. The types are determined by the experiment extension. We already have engagement event telemetry in the urlbar, so it would be nice if the extension could augment it.
This adds a details key to the event telemetry extra. It's an unstructured string we can use for whatever purpose we need. It's easy to imagine using it in future experiments to augment telemetry events with additional relevant info. I added a webext API to let extensions set and get it.
I know we can also register event telemetry at runtime. But we already have this built-in event telemetry, and analysis and the implementation are easier if we could just augment it. As an alternative, browser.urlbar could have onEngagementStart and onEngagementEnd events that the extension would listen for, and then it would record its own parallel event telemetry.
|
|
Assignee | |
Comment 2•5 years ago
|
||
Here's an alternative that adds a browser.urlbar.onEngagement event. Listeners are passed the current engagement state: start, engagement, abandonment, or discard. The extension could use this to record its own parallel telemetry (scalars, event telemetry, etc.) per engagement.
|
||
Comment 3•5 years ago
•
|
||
I think something we should avoid is the add-on being able to add any new keys to the event telemetry, because that would pretty much be a way to bypass data-review. Somehow the json details seem to already do that, I was more thinking of making details a simple string, not an object.
Would like to know what Data Stewards think about that.
|
|
Assignee | |
Comment 4•5 years ago
|
||
The details can't be a simple string because there are multiple things we want to record: the interventions that are shown and the one that the user picked. I considered having it be a comma-delimited list or something like that, but that's similar to JSON. It's a good point about data review though. So maybe the second patch is the better approach? That way the extra telemetry that the extension is collecting is clear.
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 5•5 years ago
|
||
|
|
Assignee | |
Comment 6•5 years ago
|
||
|
|
Assignee | |
Comment 7•5 years ago
|
||
Resummarizing since we're going with the alternate patch.
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
Description
•