[Tracking Requested - why for this release]: Based on experiment results, the "primary browser" flow did not improve metrics as well as "pin" then "default." MR1 upgrade dialog was implemented assuming "primary" would be good enough.

There's a couple asks that are still being finalized:

• allow for 3 screens
• potentially with images, e.g., pinning, set default animation
• potentially new strings for title/subtitle/etc

If there are new strings, we might need to land them as english only?

Currently these flows are implemented…

Windows 10

• if not default and not pinned and can pin
  • primary -> (click primary) do pin & set default -> theme…
  • primary -> (click not now) -> theme…
• if not default and already/can't pin
  • default -> (click default) set default -> theme…
  • default -> (click not now) -> theme…
• if default and not pinned and can pin
  • pin -> (click pin) do pin -> theme…
  • pin -> (click not now) -> theme…
• if default and can't pin or already pinned
  • theme -> (click theme) -> theme…
  • theme -> (click not now) -> close

Windows 7

• if not default
  • default -> (click default) set default -> close
  • default -> (click not now) -> close
• if default
  • okay -> (click okay) -> close

Mac & Linux

• if not default
  • default -> (click default) set default -> theme…
  • default -> (click not now) -> theme…
• if default
  • theme -> (click theme) -> theme…
  • theme -> (click not now) -> close

Sounds like only Windows 10 will change to something like…

• if not default and not pinned and can pin
  • pin -> (click pin) do pin -> default -> (click default) set default -> theme…
  • pin -> (click not now) -> default -> (click default) set default -> theme…
  • pin -> (click pin) do pin -> default -> (click not now) -> theme…
  • pin -> (click not now) -> default -> (click not now) -> theme…
• if default and not pinned and can pin (like before but potentially with an image, e.g., attached)
  • pin -> (click pin) do pin -> theme…
  • pin -> (click not now) -> theme…
• other flows unchanged

Most likely this bug will be touching the code changed in bug 1708056, but that bug can't be uplifted while this one will be, so we'll need a separate uplift patch.

With the addition of a conditional 3rd screen with potentially new types of interactions / UIs, a lot of the existing logic that controls what to show and how to handle buttons will need to be completely reworked. As noted in comment 1, the current 15 flows will have 4 replaced with 6 new flows while making sure the other 11 flows continue to work with the rewrite. There are automated tests that should help catch some regressions, but some of them also will need to be replaced and others at least updated to handle any differences in the telemetry.

(In reply to Ed Lee :Mardak from comment #0)

If there are new strings, we might need to land them as english only?

There's no way to add new content for translation now, especially for the onboarding. Including the time off, we're one week away from cut-off for localization, and that's the first thing users will see.

Current plan for strings is to use fluent migrations to copy over some string text from the default browser prompt defaultBrowserNotification.ftl added in bug 1701997 for MR1 and expose them as new string ids in upgradeDialog.ftl. The already translated strings can then be updated if localizers want to adjust for usage in this different context.

We'll need new images for pin and default as the current ones were only used as part of english-only experiments, and we cannot directly mirror the existing images for RTL as they include the Firefox logo.

pin: https://searchfox.org/mozilla-central/source/browser/components/newtab/data/content/windows-assets/pin-to-taskbar-v1.svg
default: https://searchfox.org/mozilla-central/source/browser/components/newtab/data/content/windows-assets/windows-default-browser.gif

Landing a new string first…

https://hg.mozilla.org/mozilla-central/rev/ada3fbe9e608

Copy / migrate strings from onboarding/defaultBrowserNotification. Add updated ltr/rtl images and show them for pin and pin+default. Dynamically adjust steps and record telemetry to identify what was shown. Handle button actions based on string ids.

For 89 beta uplift combining D115101, D115142 and D115325 resolving uplift conflicts with D114783. Copy / migrate strings from onboarding/defaultBrowserNotification. Add updated ltr/rtl images and show them for pin and pin+default. Dynamically adjust steps and record telemetry to identify what was shown. Handle button actions based on string ids. Alias upgradeDialog to aboutwelcome for now. Avoid oddness with scrollbars by hiding horizontal scroll.

Comment on attachment 9222309 [details]
Bug 1710955 - Change MR1 upgrade onboarding to Pin then Default then Theme screens r=pdahiya

Beta/Release Uplift Approval Request

• User impact if declined: Users upgrading to MR1/Proton can see upgrade dialog asking about "primary browser" instead of the more desired separate "pin" then "default"
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. run profile on 88

2. install the new build from installer (and unpin firefox and un-default if necessary)
3. launch same profile with new build

alternatively run Cc["@mozilla.org/browser/browserglue;1"].getService().wrappedJSObject._showUpgradeDialog()
OR ensure browser.startup.homepage_override.mstone=88 and browser.startup.upgradeDialog.version unset before starting the new build

• List of other uplifts needed: none
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Some of the upgrade dialog logic and telemetry had to be reworked to support 3 screens instead of always expecting 2, which still need to work for can't-pin, e.g., mac/linux. There's new type of content (showing images) that required new assets and CSS to handle as well. Also new strings (below). There are automated tests, and I've done a bunch of manual tests with langpacks that did catch some bugs before attempting to land to autoland, which as of writing this hasn't happened yet as we're awaiting final product approval of what has been designed and implemented. This attachment/patch is specifically for beta as there were merge conflicts when attempting to uplift the other reviewed patches landed/landing to m-c.
• String changes made/needed: Yes changes made. There's 1 new string and 5 copied/migrated strings. ni?flod to confirm

There was some desire to match the winning pin-a experiment branch as well as better address the recent data regarding images, but those changes would require more string changes as well as working around issues with short initial screens without items or images. So we'll land what was design and pm approved as of last week.

(In reply to Ed Lee :Mardak from comment #16)

• String changes made/needed: Yes changes made. There's 1 new string and 5 copied/migrated strings. ni?flod to confirm

Not exactly excited about these late changes, but it's OK to uplift.

https://hg.mozilla.org/mozilla-central/rev/51da471a0bad
https://hg.mozilla.org/mozilla-central/rev/d70a37d3e1b9

Comment on attachment 9222309 [details]
Bug 1710955 - Change MR1 upgrade onboarding to Pin then Default then Theme screens r=pdahiya

Approved for 89 beta 14, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/819a390c26d7

I have verified this enhancement and I can confirm the following:

• [Windows 10 v1809+] If the browser is NOT pinned and NOT set as default the following Upgrade modals will be displayed:

  1. "Pin to Taskbar" modal
  2. "Set as Default" modal
  3. "Themes" modal

• [Windows 10 v1809+] If the browser is NOT pinned but is set as default the following Upgrade modals will be displayed:

  1. "Pin to Taskbar" modal
  2. "Themes" modal

• [Windows 10 v1809+] If the browser is pinned but NOT set as default the following Upgrade modals will be displayed:

  1. "Set as Default" modal
  2. "Themes" modal

• [Windows 10 v1809+] If the browser is pinned and set as default the following Upgrade modals will be displayed:

  1. "Choose a theme" modal
  2. "Themes" modal

All the above modals are respecting the UI specifications from here.

Also, I have verified that no regressions occurred on the Upgrade flows specific to the following OSs: Windows 10 v1803, Windows 7 x64, macOS 10.15.7, Linux Mint 20 x64

Verified using the latest Firefox Nightly (90.0a1 Build ID - 20210518094531) installed on Windows 10 x64, Windows 7 x64, macOS 10.15, and Linux Mint 20 x64.

This enhancement was part of the work done on [PI-1013] - Proton: Onboarding which was signed off as GREEN. Considering this I am changing the status to VERIFIED.