1858985 - [Easy Setup Feature] - Re-implement attribution based dynamic labels

Status: ASSIGNED

(Firefox :: Messaging System, task, P2)

Description

[Negin Sauermann]

With easy setup as default experience:

• Verify whether attribution based dynamic labels can be removed or needs to be re-implemented for easy setup. Easy setup has been using Import from previous browser while original import screen (AW_IMPORT) used "Import from {browser name}"
  https://searchfox.org/mozilla-central/source/browser/components/newtab/aboutwelcome/lib/AboutWelcomeDefaults.jsm#700

original implementation bug

Comment 1

[Negin Sauermann]

Not sure who the best to ping, maybe Venetia/Najla?

Comment 2

[Ed Lee :Mardak]

There were at least 2 aspects of the user agent /previous browser attribution:

• personalized label to increase starting imports on the import screen
• auto-selecting the entry in the wizard to increase import completion

The new embedded import screen shows the most recently used browser/profile as the first/preselected dropdown entry, so it somewhat achieves both of those items at the same time.

One potential usage of the attribution as in comment 0 is to change easy setup screen checkbox choices to show something like "Import from Chrome" instead of "Import from previous browser" although this might be confusing if embedded import shows a different entry selected.

Comment 3

[Vtay]

@Najla is in a better position to answer this

Comment 4

[nbulous]

I think we need to re-implement attribution based labels because we realized that the "Import from previous browser" string was a copy paste error in our figma files that we didn't intentional test. I believe "Import from [browser name]" is what's in production for most cases.

Comment 5

[Negin Sauermann]

(In reply to nbulous from comment #4)

I think we need to re-implement attribution based labels because we realized that the "Import from previous browser" string was a copy paste error in our figma files that we didn't intentional test. I believe "Import from [browser name]" is what's in production for most cases.

Just wanted to clarify, I don't think "Import from previous browser" was a copy paste error. It's possible to still see "Import from previous browser" if a user agent is not provided, that's the string we fallback to.

However, I believe we added the fluent strings for easy setup in this patch 11 months ago which uses "Import from previous browser" in all cases for easy setup rather than re-purposing the user agent strings which uses "Import from ${previousBrowser}" if a user agent is found. Based off Ed's comment this may have been an intentional decision given that migration wizard could show a different browser on the subsequent screen. I'm not sure if I was a part of this discussion so I may be missing some context in that regard. Let me know what you think!

Comment 6

[Negin Sauermann]

Hi Mike, tagging you into this discussion to get a bit of context from you!

We were hoping to re-introduce dynamic import labels on the easy setup screen (i.e. Import from ${browserName} vs Import from previous browser. Previously this was done here with the mr1-onboarding-import-primary-button-label-attribution string id as of this patch.

The concern is that what we have as the Import from ${browserName} on the easy setup screen may not match the default browser select option for embedded migration wizard and it's not obvious to me how that default is selected in embedded migration wizard if you wouldn't mind explaining!

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Hey Negin!

Thanks for tagging me. The MigrationWizardParent gets a list of all browser/profile pairs that are available, and then tries to sort them from "lastModifiedDate". It's a little awkward, because instead of calculating the lastModifiedDate for each browser/profile pair, we calculate the lastModifiedDate for just the browser - meaning that if you used Safari recently, and then one of your Chrome profiles more recently, then I believe all Chrome profiles will appear above Safari. Not amazing.

Our techniques for detecting "lastModifiedDate" are also rather shaky (we stat various files in the profile path looking at the last time they were touched), and if we can't determine them, we fallback to Date(0), which puts that browser at the bottom of the sorting pile.

Looking at the old patch, it looks like the ua in the attribution code is what we originally used to make the selection. I think that's fair. We'll need to build out a way of having the migration wizard indicate that it'd prefer that kind of browser as its default selection.

Here's what I suggest:

1. Modify the about:welcome code that embeds the migration-wizard to set an attribute like "default-migrator-key" on the <migration-wizard>, with the key from the attribution codes.
2. Update the #requestState method here to look for that attribute, and if one exists, to pass it as a second argument to #populateMigrators, since it accepts an optional migrator key to make that initial selection.
3. Update #onSelectionChanged in migration-wizard.mjs to be a bit more defensive - since we're sometimes going to be getting a migrator key externally, we should ensure that the key matches something in our list before attempting to auto-select it. That means updating this chunk here so that we check that the panelitem exists before calling this.#onBrowserProfileSelectionChanged - otherwise, we skip that step.
4. We'll want to add an automated test for this. That'll probably end up being the harder part, but we can deal with that when we get there.

Comment 8

[Negin Sauermann]

This is being re-prioritized as a P2 in favour of higher priority on-train work that will be required for upcoming about:welcome surveys.

Comment 9

[Negin Sauermann]

Going to remove the iteration as this is not being actively worked on (and it's showing up in the engineering allocation).