Stop migrating profiles into App Package builds
Categories
(Firefox :: Installer, task)
Tracking
()
People
(Reporter: nalexander, Assigned: nalexander)
References
(Depends on 1 open bug)
Details
(Whiteboard: [fidedi-installer])
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
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).
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 1•3 years ago
|
||
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.
|
|
Assignee | |
Comment 2•3 years ago
|
||
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.
| Comment hidden (obsolete) |
|
|
Assignee | |
Comment 4•3 years ago
|
||
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.
|
|
Assignee | |
Comment 5•3 years ago
|
||
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:
|
|
Assignee | |
Updated•3 years ago
|
|
||
Comment 7•3 years ago
|
||
| bugherder | ||
|
|
||
Comment 8•3 years ago
|
||
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.
|
|
||
Comment 9•3 years ago
|
||
| bugherder uplift | ||
|
||
Updated•3 years ago
|
|
||
Comment 10•3 years ago
|
||
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).
Description
•