Closed Bug 1597610 Opened 4 years ago Closed 4 years ago

Add browser.urlbar.onEngagement WebExtensions API

Categories

(Firefox :: Address Bar, task, P1)

task
Points:
3

Tracking

()

RESOLVED FIXED
Firefox 72
Iteration:
72.3 - Nov 18 - Dec 1
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.

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.

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.

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.

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.

Attachment #9109886 - Attachment is obsolete: true

Resummarizing since we're going with the alternate patch.

Summary: Let consumers set urlbar event telemetry details → Add browser.urlbar.onEngagement WebExtensions API
Pushed by dwillcoxon@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a4cf47d45dc8
Add browser.urlbar.onEngagement WebExtensions API. r=mak,mixedpuppy
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 72
Regressions: 1599406
You need to log in before you can comment on or make changes to this bug.