1853955 - Update telemetry for Migration Wizard to record entrypoint when wizard is embedded

Status: NEW

(Firefox :: Migration, task, P1)

Description

[Kelly Cochrane [:kcochrane]]

Originally requested in bug 1833674, we want the ability to record the entrypoint when the migration wizard is embedded (such as in Firefox View).

From mconley's comment in bug 1833674, here's what he suggests we do to accomplish this:

Here's the current state of Telemetry for the migration wizard:

We have a mixture of Histograms, Scalars, and Events. We use this histogram to try to measure entrypoints into the migration wizard. But there's a flaw with this! It's really a measurement of the entrypoints into MigrationUtils.showMigrationWizard, which is called by places that open the about:preferences instance of the migration wizard, or the legacy dialog. Embedded versions of the migration wizard don't use showMigrationWizard at all, and so aren't counted.

This also just tells us how people got into the wizard via showMigrationWizard - it doesn't tell us whether or not that entrypoint resulted in a successful migration (maybe the user opened and closed the migration wizard right away from some entrypoint - we don't have a way of knowing that!)

We do have events for each stage of the migration wizard. This seems like a ripe place to annotate with an embedder identification string as an extra_key. That way, we can theoretically measure how many migration_finished events occur with the history extra_key set to 1 and the firefox-view identifier string.

So, what I suggest we do is the following:

1. Update the description of this histogram to indicate that it's measuring calls to showMigrationWizard, but doesn't include embedded instances of the migration wizard. That's just some housekeeping.
2. Add a new extra_key for each event called "embedder_id" or something. Some of the events already have extra_keys, which we can add to - others will need the extra_keys section added. The description of embedder_id is something like "The unique ID of the surface that the migration wizard is embedded in."
3. For every place that we embed the migration-wizard, add the new attribute.

So, for example, the preferences/main.js instance could have embedder-id="preferences", and the history.mjs would could have embedder-id="firefox-view". These are the identifiers that we'll use for our events extra_key. Note that it's intentional that the attributes have dashes, and the event extra_key names have underscores. Different conventions for different contexts (Telemetry vs DOM).

4. Update MigrationWizardChild's #sendTelemetryEvent implementation to include the embedder-id in the { type, args } structure going up, so { type, args, embedder_id }.

5. In MigrationWizardParent, where we respond to the RecordEvent message, if args is non-null, insert the embedder_id in it. If not, create an args object, and put the embedder_id in it.

At that point, test each of the surfaces and make sure the events and embedder IDs are showing up in about:telemetry#events-tab.

Unfortunately, Nolan from CalState never finished his patch to add Event telemetry tests, otherwise I'd suggest you'd add to them. If you're willing to go the extra mile, you could try to polish that off, and then also add tests for the embedder-id.

Note:
For Step 4, you can get at the underlying the <migration-wizard> element with this.#wizardEl, but Xray wrappers might prevent you from getting it directly. Normally, we'd be very skeptical of attributes coming from content, but since the migration-wizard actors are only allowed on internal pages, I believe we can get at the attribute like this:
let embedderID = Cu.waiveXrays(this.#wizardEl).getAttribute("embedder-id");

Comment 1

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

marking P1, since it's being actively worked

Comment 2

[Kelly Cochrane [:kcochrane]]

Going to unassign this from myself for now as I work through higher priority work. :sclements is going to double check with product on where priority should be for this work. While I may end up picking this back up eventually, but I just want to again thank :mconley for giving detailed instructions on how we might implement this.