1901540 - Returning profiles should a differentiated about:welcome flow after refreshing their profile via the Windows stub installer

Status: NEW

(Firefox :: Messaging System, defect, P2)

Description

[Meg Viar [:mviar]]

This bug captures the investigation and any corresponding on-train work to enable the ability to differentiate the about:welcome flow for users who have reinstalled Firefox and refreshed their profile via the stub installer. This may include identifying and/or implementing a method for targeting these users in about:welcome. We can tap into the existing capability to use screen-level targeting for customizing which cards are shown to the user during the about:welcome flow.

---

This bug is was initially created to investigate why users who refresh their profile in the Windows stub installer are still taken to the first run flow in about:welcome after reinstall. See notes from previous bug below:

Bug 1898609 surfaced a bug on Windows that occurs when Firefox is installed via the stub installer and a user opts in to "refreshing" Firefox. These users are taken to about:welcome, despite refresh logic intended to prevent this. They also currently see an infobar in about:welcome asking them to refresh, even if they already opted in to doing so using the stub installer checkbox.

:pdahiya noted that this refresh logic isn't being executed for the restore profile flow and suggested investigating whether MOZ_RESET_PROFILE_MIGRATE_SESSION gets set in time.

Also see :aminomancer's comment suggesting a check for trailhead.firstrun.didSeeAboutWelcome in BrowserContentHandler where we determine whether about:welcome is going to show.

Comment 1

[Meg Viar [:mviar]]

Attachment: WIP: Bug 1901540 - Set homepage overrides to ensure users don't see about:welcome after resetting their profile via the stub installer

Comment 2

[Meg Viar [:mviar]]

I've done some investigation into this issue and have a proposed solution.

When a user checks the option to refresh their profile in the stub installer, Firefox is launched with the command line arguments -reset profile -migration -first-startup. When a user resets their profile from somewhere like about:support, the env var “MOZ_RESET_PROFILE_RESTART” is set to 1. This does not occur in the stub installer case.

SelectProfile in nsAppRunner.cpp checks for either the MOZ_RESET_PROFILE_RESTART env var OR the reset-profile command line argument to set a var gDoProfileReset (see here). Later, if both gDoProfileReset AND the env var MOZ_RESET_PROFILE_RESTART are truthy, then the latter is reset to having no value and the env var MOZ_RESET_PROFILE_MIGRATE_SESSION is set to 1 (see here).

Later, the Firefox Profile Migrator checks to see if MOZ_RESET_PROFILE_MIGRATE_SESSION if truthy. If so, it performs some logic that includes reseting the homepage_override prefs so that the browser doesn’t override the session with a homepage other than the about:welcomeback page that should show in this case.

In the case of a profile reset triggered by the stub installer, I believe we want run reset the homepage override prefs as described above to avoid showing about:welcome, but do not want to migrate session data.

My proposed solution is to set MOZ_RESET_PROFILE_NEW_SESSION=1 in nsAppRunner.cpp if we are resetting the profile, but the MOZ_RESET_PROFILE_MIGRATE_SESSION env var wasn't previously set by ResetProfile. Then, add an else if condition after this check in FirefoxProfileMigrator that just resets the milestone prefs if MOZ_RESET_PROFILE_NEW_SESSION is truthy.

Comment 3

[Meg Viar [:mviar]]

:Gijs, I saw you did some work on the profile restart login in nsAppRunner.cpp a couple years ago. Does the above approach sound reasonable to you? I've attached a WIP patch.

Comment 4

[:Gijs (he/him)]

The proposed solution sounds reasonable enough, though I would probably suggest tweaking it to have just 1 env var, maybe MOZ_PROFILE_RESET_SESSION and set the value to restore or new or empty / some other value as needed, which IMO would simplify some of the checks and reduce how many different indicators of state we have flying around. Does that make sense?

Comment 5

[Meg Viar [:mviar]]

Thanks for the input, that sounds sensible to me. I'll update the patch and start investigating how to approach automated testing.

Comment 6

[Meg Viar [:mviar]]

Moving this to 131.2 when I'm back from moz week / PTO. Per discussion in the patch, we'll add a marionette test before landing.

Comment 7

[Phabricator Automation]

Comment on attachment 9414177 [details]
WIP: Bug 1901540 - Set homepage overrides to ensure users don't see about:welcome after resetting their profile via the stub installer

Revision D217301 was moved to bug 1898609. Setting attachment 9414177 [details] to obsolete.

Comment 8

[Meg Viar [:mviar]]

After further discussion with product, we decided to continue showing about:welcome after profile refresh. The goal is to eventually differentiate the experience for these returning users. I've moved the previously attached patch to bug 1898609, which was created to prevent the infobar from appearing after profile refresh (it already has a patch that's a child of this one). This bug can be updated to focus on ensuring we have a means of identifying/targeting users returning from a profile refresh in the about:welcome flow.