Closed Bug 1736876 Opened 1 month ago Closed 1 month ago

Stop migrating profiles into App Package builds

Categories

(Firefox :: Installer, task)

task

Tracking

()

VERIFIED FIXED
95 Branch
Tracking Status
firefox94 + verified
firefox95 + verified

People

(Reporter: nalexander, Assigned: nalexander)

References

(Depends on 1 open bug)

Details

(Whiteboard: [fidedi-installer])

Attachments

(1 file)

Bug 1709969 implemented migrating from an existing profile when running out of an app package. Unfortunately, the experience isn't ideal when an existing Firefox is running. Bug 1734000 tracks improving that experience, but won't hit Firefox 94, which is the first release we intend to publish in the Microsoft Store. This ticket tracks either reverting Bug 1709969, neutering its functionality, or making it conditional in some other way -- perhaps behind a Gecko preference (although I expect the tight time constraint won't allow that).

No longer depends on: 1736702

The product experience migrating a profile when a non-MSIX Firefox is
running is not ideal, so we're going to always start with a fresh
profile for simplicity.

This is a straight backout of the "meat" of Bug 1709969 - Migrate from
an existing profile when running from an app package for the first
time, namely hg backout -r 5136d2f684012dc3d586dcb10374f8c6eda8b6d7.
The changes from follow-up Bug 1723298 (correcting test failures on
devedition), namely revision a4bca433c8f7003a90fda61248f38d9b389c394e,
were manually reverted and the test files deleted.

Try build is percolating at https://treeherder.mozilla.org/jobs?repo=try&revision=4818d44a75758a72fbc11b510fd52a51f6eeed10. I'll verify that we have green profile xpcshell tests as the builds complete.

I was confused by the outcomes of #c3, so I talked them through with :agashlin. He pointed out that I was not deleting high enough up the directory hierarchy to trigger the relevant behavioural change. This comment obsoletes #c3, with the correct places deleted; and the behaviour is what I expect.

Scenarios

There are 3 scenarios to test. I prepared the test environment by downloading:

$ wget https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JiGBrPP-TfiG-rbWcmK7eg/runs/0/artifacts/public/build/target.installer.msix

I have Firefox Nightly already installed in C:\Program Files\Firefox Nightly.

No existing AppData\Roaming

PS C:\Users\nalexander> Get-AppPackage -Name "*FirefoxNightly*" | Remove-AppPackage
PS C:\Users\nalexander> Remove-Item -Recurse C:\Users\nalexander\AppData\Roaming\Mozilla
PS C:\Users\nalexander> Add-AppxPackage C:\Users\nalexander\Mozilla\gecko\target.installer.msix
PS C:\Users\nalexander> Start-Process explorer.exe -Argument 'shell:appsFolder\Mozilla.MozillaFirefoxNightly_5x4grbbqzn2q4!FIREFOX'

Now open about:support, witness profile in virtualized AppData\Roaming, like C:\Users\nalexander\AppData\Local\Packages\Mozilla.MozillaFirefoxNightly_5x4grbbqzn2q4\LocalCache\Roaming\Mozilla\Firefox\Profiles\07x2qw0e.default-default.

Existing AppData\Roaming

PS C:\Users\nalexander> Get-AppPackage -Name "*FirefoxNightly*" | Remove-AppPackage
PS C:\Users\nalexander> Remove-Item -Recurse C:\Users\nalexander\AppData\Roaming\Mozilla
PS C:\Users\nalexander> Start-Process "C:\Program Files\Firefox Nightly\firefox.exe"

After launching existing Firefox Nightly, open about:support, witness default-nightly profile like C:\Users\nalexander\AppData\Roaming\Mozilla\Firefox\Profiles\p53ylbhm.default-nightly. Close Firefox Nightly.

PS C:\Users\nalexander> Add-AppxPackage C:\Users\nalexander\Mozilla\gecko\target.installer.msix
PS C:\Users\nalexander> Start-Process explorer.exe -Argument 'shell:appsFolder\Mozilla.MozillaFirefoxNightly_5x4grbbqzn2q4!FIREFOX'

Now open about:support, witness profile in unvirtualized AppData\Roaming, like C:\Users\nalexander\AppData\Roaming\Mozilla\Firefox\Profiles\fxtx1rjv.default-default. Note that the profile is not the same profile as the non-MSIX Firefox Nightly used.

Running Firefox Nightly

PS C:\Users\nalexander> Get-AppPackage -Name "*FirefoxNightly*" | Remove-AppPackage
PS C:\Users\nalexander> Remove-Item -Recurse C:\Users\nalexander\AppData\Roaming\Mozilla
PS C:\Users\nalexander> Start-Process "C:\Program Files\Firefox Nightly\firefox.exe"

Leave this Firefox Nightly running. Then:

PS C:\Users\nalexander> Add-AppxPackage C:\Users\nalexander\Mozilla\gecko\target.installer.msix
PS C:\Users\nalexander> Start-Process explorer.exe -Argument 'shell:appsFolder\Mozilla.MozillaFirefoxNightly_5x4grbbqzn2q4!FIREFOX'

Now open about:support, witness profile in unvirtualized AppData\Roaming, like C:\Users\nalexander\AppData\Roaming\Mozilla\Firefox\Profiles\hshf4w28.default-default. Note again: not the same profile as the non-MSIX Firefox Nightly is actively using.

Conclusion

This is as expected. MSIX users will have a new profile (specific to the MSIX package family name, i.e., not shared between Release and Beta) that is not migrated from any existing profile. Existing Firefox users those with AppData\Roaming\Mozilla, will have profiles in that directory. New Firefox users will have profiles in their virtualized location. These details are as they were with the profile migration in place after Bug 1709969, AFAIK.

Comment on attachment 9246917 [details]
Bug 1736876 - Stop migrating profiles into App Package builds. r?agashlin

Beta/Release Uplift Approval Request

  • User impact if declined: Existing Firefox users who try the MSIX/Microsoft Store version will have their existing profile migrated into a per-MSIX profile. The user experience has proved to not be ideal: there's migration UI before Firefox starts, which can be surprising. And if the existing profile chosen for migration cannot be locked, UI that is not specific to migration and packages is shown, and the functionality of that UI doesn't work (Bug 1736702). Product (Romain) has asked that we just go with a new profile for all MSIX/Microsoft Store users as a simpler and more reliable solution.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See the detailed test instructions in https://bugzilla.mozilla.org/show_bug.cgi?id=1736876#c4.
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): This commit is a back out (with minor additional backouts) rather than new development. The functionality being removed should only impact MSIX/Microsoft Store users, of which there are none at this time. All of the risk is due to the extremely tight schedule: decision to execution to landing and uplift will be <48 hours.
  • String changes made/needed:
Attachment #9246917 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by nalexander@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2946940c35df
Stop migrating profiles into App Package builds. r=agashlin
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

Comment on attachment 9246917 [details]
Bug 1736876 - Stop migrating profiles into App Package builds. r?agashlin

Important fix needed for our MSIX builds before launching in the Microsoft Store with the Fx94 release. Approved for 94.0b9.

Attachment #9246917 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Verified that the migration is not occurring by following the scenarios provided by Nick. We tested on two different Win 11 systems, with Firefox 95.0a1 (we were able to test Nightly only if we installed the certificates first) and Firefox 94.0b10. For beta testing we launched the builds manually (not by the terminal commands) and the profiles created by MSIX builds were default-beta-1 (and not default-default as with Nightly).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1737604
You need to log in before you can comment on or make changes to this bug.