2025314 - asyncFlushCurrentProfile assumes all toolkit profiles have different store identifiers and overwrites the wrong profile if this isn't the case

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P1)

Description

[Alice0775 White]

Firefox launches using a profile other than the one selected with firefox -p.

Steps to reproduce:

1. Prerequisite: There are many profiles.
2. Start nightly Firefox -p to launch Profile selector and choose a profile, then Start Nightly.
3. Open about:support and check profile folder

Actual results:
Firefox launches using a profile other than the one selected.
And profiles.ini is broken.

Expected results:
Firefox should launch using the selected profile.

Comment 2

[Alice0775 White]

It happened again.

Comment 3

[Alice0775 White]

Here is an example of a profiles.ini file (number of profiles is > 50)

[Profile1]
Name=profilename111
IsRelative=1
Path=Profiles/blablabla.profilename111

[Profile2]
Name=profilename222
IsRelative=1
Path=Profiles/blablabla.profilename222

... ...

1. Run firefox -p, select the profile profilename222, and start and close the browser.
2. Run firefox -p, select the profile profilename111, and start and close the browser.

As a result, the path for profilename222 is unexpectedly overwritten as follows:

[Profile1]
Name=profilename111
IsRelative=1
Path=Profiles/blablabla.profilename111

[Profile2]
Name=profilename222
IsRelative=1
Path=Profiles/blablabla.profilename111

... ...

Comment 4

[Alice0775 White]

[Tracking Requested - why for this release]: Profile system will be broken after launch browser with different profiles.

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=97386e6e20491aa6291afc8a6f5d4ee69bcdbef5&tochange=7bada62955268708db3bb09358944ee65c072f13

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:mossop, since you are the author of the regressor, bug 2022782, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[Dave Townsend [:mossop]]

Bug 2022782 only really changed the path when you've used selectable profiles previously so I assume that is the case here.

(In reply to Alice0775 White from comment #3)

[Profile1]
Name=profilename111
IsRelative=1
Path=Profiles/blablabla.profilename111

[Profile2]
Name=profilename222
IsRelative=1
Path=Profiles/blablabla.profilename222

Was there no StoreID property for these?

For both profiles please run the following two snippets in the browser console and let me know what they return:

SelectableProfileService.storeID

await SelectableProfileService.getAllProfiles().then(p => p.map(p => p.path))

Comment 7

[Alice0775 White]

profile1:

21:43:50.926 SelectableProfileService.storeID
21:43:50.966 "2e42c58b"
21:44:24.933 await SelectableProfileService.getAllProfiles().then(p => p.map(p => p.path))
21:44:25.054
Array []
​
length: 0
​
<prototype>: Array []
​
<global>: SystemGlobal { crypto: Crypto, indexedDB: IDBFactory, locks: LockManager, … }

profile2:

21:45:25.566 SelectableProfileService.storeID
21:45:25.642 "2e42c58b" 
21:45:36.558 await SelectableProfileService.getAllProfiles().then(p => p.map(p => p.path))
21:45:36.754
Array []
​
length: 0
​
<prototype>: Array []
​
<global>: SystemGlobal { crypto: Crypto, indexedDB: IDBFactory, locks: LockManager, … }

Comment 8

[Dave Townsend [:mossop]]

What are the values of browser.profiles.created and browser.profiles.enabled in about:config in both cases?

Comment 9

[Alice0775 White]

pofile1:

browser.profiles.created true
browser.profiles.enabled true

profile2:

browser.profiles.created true
browser.profiles.enabled true

Comment 10

[Dave Townsend [:mossop]]

Ok this is somewhat related to bug 1991913. Somehow both of those profiles are assigned to the same store ID which should never happen, and on top of that the store doesn't contain any profiles leaving things in a bit of a broken state. I can see why bug 2022782 has made this start behaving more strangely.

Comment 11

[Alice0775 White]

I suspect the presence of duplicate storeIDs is due to the following:
“Copying the profile folder using a file manager, renaming that folder using the file manager, and then registering it with the Profile Manager.”

This approach hadn’t caused any issues until now, but the problem may have surfaced after the changes made in bug 2022782.

Comment 12

[Dave Townsend [:mossop]]

Attachment: Bug 2025314: Only flush profiles.ini when necessary and safe. r=#profiles-reviewers!

We currently attempt to flush whenever a browser window is activated. In the
most common case this doesn't actually change the profile, it is just switching
between windows of the same profile. The only time we do still need to flush in
this case is if another instance has updated profiles.ini in the meantime.

Additionally this makes asyncFlushCurrentProfile safer by making it fail if more
than one profile has the same store ID or path if we are falling back to paths.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 2022782

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8e1e54da8194
https://hg.mozilla.org/integration/autoland/rev/ce9ae51c619e
Only flush profiles.ini when necessary and safe. r=profiles-reviewers,jhirsch

Comment 15

[Cristian Tuns]

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

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:mossop, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox150 to wontfix.

For more information, please visit BugBot documentation.

Comment 17

[Dave Townsend [:mossop]]

Yes we would want to uplift but I want to give this a couple of days bake time on Nightly first.

Alice are you able to verify that this fixes the issue for you in the next nightly?

Comment 18

[Alice0775 White]

STR For testing:

1. I delete Profile Groups folder and installs.ini and profiles.ini file.
2. And I registered two profiles that contain a prefs.js file with the same toolkit.profiles.storeID value.

Results:
Even if I use latest Nightly151.0a1 (20260326095454), the issue is reproduced.

---

I followed the same steps as in Step 1 above.
And removed toolkit.profiles.storeID from the prefs.js file for each profile, and then re-registered them.

After doing so, the issue no longer occurred.

Comment 19

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: In an edge case users of the old profile management system may lose access to some of their profiles is they have manually modified their profiles.ini file.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: The code changes are well exercised by tests and this has been baking on nightly for nearly two weeks
• String changes made/needed?: None
• Is Android affected?: no

Comment 20

[Dave Townsend [:mossop]]

Attachment: Bug 2025314: Only flush profiles.ini when necessary and safe.

We currently attempt to flush whenever a browser window is activated. In the
most common case this doesn't actually change the profile, it is just switching
between windows of the same profile. The only time we do still need to flush in
this case is if another instance has updated profiles.ini in the meantime.

Additionally this makes asyncFlushCurrentProfile safer by making it fail if more
than one profile has the same store ID or path if we are falling back to paths.

Original Revision: https://phabricator.services.mozilla.com/D289780

Comment 21

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c340cb767faa
https://hg.mozilla.org/releases/mozilla-beta/rev/5fa34af4fbde