Bugzilla

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](https://bugzilla.mozilla.org/show_bug.cgi?id=1833674#c3) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Histograms.json#8678-8703) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Events.yaml#1059-1234) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Histograms.json#8678-8703) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Events.yaml#1059-1234) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/migration/content/migration-dialog-window.html#35) [place](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/newtab/content-src/aboutwelcome/components/EmbeddedMigrationWizard.jsx#34-38) [that](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/firefoxview/history.mjs#239) [we](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/preferences/main.js#2147) 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`](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/migration/MigrationWizardChild.sys.mjs#167-169) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/migration/MigrationWizardParent.sys.mjs#184-190), 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1825875), 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.

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](https://bugzilla.mozilla.org/show_bug.cgi?id=1833674#c3) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Histograms.json#8678-8703) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Events.yaml#1059-1234) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Histograms.json#8678-8703) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/toolkit/components/telemetry/Events.yaml#1059-1234) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/migration/content/migration-dialog-window.html#35) [place](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/newtab/content-src/aboutwelcome/components/EmbeddedMigrationWizard.jsx#34-38) [that](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/firefoxview/history.mjs#239) [we](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/preferences/main.js#2147) 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`](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/migration/MigrationWizardChild.sys.mjs#167-169) 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](https://searchfox.org/mozilla-central/rev/c56cc57d547a5febcc34160e581f9d58c0326aa7/browser/components/migration/MigrationWizardParent.sys.mjs#184-190), 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1825875), 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](https://firefox-source-docs.mozilla.org/dom/scriptSecurity/xray_vision.html) 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");```