See https://mana.mozilla.org/wiki/display/FIREFOX/Upgrade+User+Onboarding+Impact

This is offtrain targeting Fx89

We probably can't use nimbus defaults for startup in 89 and that we changed it to use the fallback pref with bug 1705725, but given the many checks to display-or-not, we might be able to use a normandy default pref change to the whatsNewPanel as it has relatively low population and behavior is turned off in 89 anyway.

https://searchfox.org/mozilla-central/rev/716d7cd80b3dcd81c005ad13b51d3e6a85bd7e73/browser/components/BrowserGlue.jsm#3748-3774

Ana to help figure out details and file PI bug for this

I just tested on nimbus https://settings.stage.mozaws.net/v1/buckets/main/collections/nimbus-desktop-experiments/records/test-upgrade-dialog-experiment

Upgrading from nightly 88 to nightly 90 correctly showed the upgrade dialog and had appropriate telemetry in control/enabled as well as not-enrolled/default-enabled branches while holdback/disabled did not show the upgrade dialog and also had telemetry.

We won't need to use nimbus defaults nor normandy default pref change from comment 0 as we can enroll existing users towards the end of 88 before they upgrade to 89, and the experiment data for featureId: upgradeDialog will be used at 89 startup.

We can use the normal nimbus web interface to deploy this once we can select "Upgrade Dialog" from the feature configuration drop down with https://github.com/mozilla/experimenter/issues/5227

Also documenting that there's regular event telemetry under upgrade_dialog# that was added as part of bug 1697222.

https://searchfox.org/mozilla-central/rev/6b099d836c882bc155d2ef285e0ad0ab9f5038f6/toolkit/components/telemetry/Events.yaml#555-580

E.g., holdback branch will have upgrade_dialog#trigger#reason#disabled while control and not-enrolled should have upgrade_dialog#trigger#reason#satisfied when upgrading to 89

When the upgrade dialog is shown, there is telemetry for calculating click-through rates from bug 1706489, e.g.:

upgrade_dialog#trigger#reason#satisfied                               ; showing upgrade dialog
upgrade_dialog#content#show#0                                         ; intro screen shown (screen index 0)
upgrade_dialog#content#show#upgrade-dialog-new-primary-default-button ; "default browser" button shown
upgrade_dialog#content#button#upgrade-dialog-new-secondary-button     ; user clicked "not now"
upgrade_dialog#content#show#1                                         ; theme screen shown (screen index 1)
upgrade_dialog#content#theme#2                                        ; user selected dark theme (position 2)
upgrade_dialog#content#button#upgrade-dialog-theme-primary-button     ; user clicked "save theme"
upgrade_dialog#content#close#complete                                 ; dialog closed normally

The string ids for identifying which buttons are shown/clicked are https://searchfox.org/mozilla-central/source/browser/locales/en-US/browser/upgradeDialog.ftl except on windows 7 the string can be "cfr-doorhanger-doh-primary-button-2" reused by bug 1707141.

We're back to planning for a normandy pref change experiment. Nimbus added upgradeDialog to SYNC_ACCESS_FEATURES in bug 1705725 for 89 allowing for accessing experiment data without waiting for async disk reads. But that means in 88, nimbus enrolling users for upgradeDialog can result in a race condition when upgrading to 89 as experiment data read from disk could happen after we decide to show the upgrade dialog. I.e., the holdback branch could result in some users with slow disks seeing the upgrade dialog.

With a normandy pref change, I believe the current general plan is to have 2 branches:

• holdback branch sets user pref branch browser.startup.upgradeDialog.version to 90 pretending a newer version of the dialog was shown resulting in no upgrade dialog shown when upgrading from 88 -> 89
• control branch either changes no prefs or if it requires a pref, set user pref branch some.dummy.pref to something resulting in normal behavior of upgrade dialog shown

The user pref branch is desired so that it's already set when 89 starts avoiding race conditions. Control branch "looks at" some dummy pref to avoid unenrollment but notably not watching browser.startup.upgradeDialog.version as that will get set to 89 when the upgrade dialog is shown. Also important to note that browser.startup.upgradeDialog.version has no default value in 88 or 89 (or any Firefox version), so that should avoid normandy wanting to unenroll for a pref change.

Bug 1711121 was experimenter wontfix as we now have a nimbus experiment that relies on bug 1710955 change to ExperimentAPI:
https://experimenter.services.mozilla.com/nimbus/onboarding-modal-experiment

We've finished running our experiment test cases and sent a GREEN sign off via e-mail. You can see it here.

This is launched and enrolling users

https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/nimbus-desktop-experiments/records/onboarding-modal-experiment