2000125 - If a profile ends up with the wrong value in toolkit.profiles.storeID then the profiles feature is broken

Status: UNCONFIRMED

(Toolkit :: Startup and Profile System, defect)

Description

[André Costa]

Attachment: The profile manager showing all profiles; the one I am trying to remove is the last one to the right

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0

Steps to reproduce:

I already had a personal and work profile. I opened Firefox with the default (personal) profile, and created a new work profile, and copied everything (all the files) from my old work profile on top of the newly created work profile. This did not have the outcome I expected (I know now I should have only copied some files). I then created a new work profile, with a different name, and this time I copied only the necessary files (bookmarks, logins, passwords etc.) from the old work profile. This time it worked. Then I tried to remove the first work profile I created, by clicking on the corresponding delete button on the Profile Manager.

Actual results:

A new Firefox instance with this profile is opened on the "about:deleteprofile" URL, but nothing else happens. Clicking on the hamburger menu shows no profile menu item.

Expected results:

A dialog showing what will be deleted and asking for confirmation should have appeared.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Dave Townsend [:mossop]]

I think what has happened here is the profile you want to delete has ended up with the profiles feature disabled. If you open it and go to about:config you should be able to toggle browser.profiles.enabled to true and after that functionality like deleting should work correctly. Let me know if that resolves the issue.

Comment 3

[André Costa]

Hi Dave, thanks for lending a hand. Unfortunately, browser.profiles.enabled was already set to true (I tried to append a screenshot here but apparently it is not possible). I also restarted this profile in troubleshoot mode, but it didn't help either.

Comparing the settings from this profile with a functioning profile shows a couple of differences (between brackets are the values of the functioning profile):

browser.profiles.created is missing [true]
browser.profiles.profile-name.updated: false [true]

Is there any other place I should look for any clues?

Comment 4

[Dave Townsend [:mossop]]

When the new profile loads and attempts to display about:deleteprofile does any error display in the browser console?

Can you also look at the values of the preference toolkit.profiles.storeID in both profiles?

Comment 5

[André Costa]

Console shows nothing for the about:deleteprofile .

Good catch, the values are indeed different for toolkit.profiles.storeID . I had already noticed that, but I thought it was expected. Comparing the values on the three different profiles I have, both the two working ones have the same storeID, while only this non-working profile has a different one. Should I try to set it to the same value of the other profiles?

Comment 6

[Dave Townsend [:mossop]]

(In reply to André Costa from comment #5)

Console shows nothing for the about:deleteprofile .

Good catch, the values are indeed different for toolkit.profiles.storeID . I had already noticed that, but I thought it was expected. Comparing the values on the three different profiles I have, both the two working ones have the same storeID, while only this non-working profile has a different one. Should I try to set it to the same value of the other profiles?

Yes and then restart and I think that will fix it.

Comment 7

[André Costa]

Yes and then restart and I think that will fix it.

You nailed it. I reset the storeID to the value of the other profiles, and then after a restart I could remove the duplicate profile (the about:deleteprofile URL appeared with the confirmation dialog).

Thanks for the help! Please feel free to close this issue as RESOLVED.

Comment 8

[Dave Townsend [:mossop]]

I've seen a couple of cases now where the storeID has become incorrect. In some cases the reason is clear in others I haven't been able to identify it. But I want to attempt to automatically recover when this happens as it leaves a pretty broken experience.

Comment 10

[Dave Townsend [:mossop]]

Attachment: WIP: Bug 2000125: Ensure that profiles launched from the profile service have the correct store ID. r=#profiles-reviewers!

If a profile's store ID as held in the preference toolkit.profiles.storeID is wrong then we end up
in a bad place because it no longer matches that of profiles.ini and so we cannot update the default
for the group and we now point to the wrong database and so cannot list profiles or even change the
current profile.

This patch passes the group ID when launching profiles via the new profile service allowing us to
reset the preference to the correct value in any case where it is wrong.

Comment 11

[Dave Townsend [:mossop]]

The bug here is that a user may have multiple profiles but for some reason they have different storeIDs. So in profile A the profiles menu lists profile B but when you launch it because profile B is using a different store it has a different list of profiles. In fact in every case I've seen profile B doesn't think it's ever used profiles and so no profiles appear and things like the profile deletion and edit UI are broken.

The attached patch recovers from this by passing the storeID on the command line when we launch a profile through the profiles UI. If the launched profile's preference doesn't match then we overwrite it with the correct storeID.

What I want to know is how this impacts Nimbus and OMC. In some cases this profile will have run previously with one storeID and then will change to a different storeID on the next startup. Does this cause anything in the rest of the profile to now be out of sync with what is in the new store. Predominantly I am thinking preferences that may have been set by experiments but I'm sure there may be other things too. And if so is there a better way to handle this?

Comment 12

[Beth Rennie [:beth] (she/her)]

(In reply to Dave Townsend [:mossop] from comment #11)

What I want to know is how this impacts Nimbus and OMC. In some cases this profile will have run previously with one storeID and then will change to a different storeID on the next startup. Does this cause anything in the rest of the profile to now be out of sync with what is in the new store. Predominantly I am thinking preferences that may have been set by experiments but I'm sure there may be other things too. And if so is there a better way to handle this?

Yeah. If a profile is launched in multiple groups/multiple stores, there will be Nimbus state associated with that profile in all of those stores. Lets say a profile is launched in group A by mistake and this patch moves it back to group B. While part of group A it would enroll in experiments/rollouts, but all the state would be associated with group A and it would be lost when it launched as part of group B. This could mean that there are preferences stuck forever that Nimbus cannot reset (because it doesn't know about them).

Comment 13

[Dave Townsend [:mossop]]

(In reply to Beth Rennie [:beth] (she/her) from comment #12)

(In reply to Dave Townsend [:mossop] from comment #11)

What I want to know is how this impacts Nimbus and OMC. In some cases this profile will have run previously with one storeID and then will change to a different storeID on the next startup. Does this cause anything in the rest of the profile to now be out of sync with what is in the new store. Predominantly I am thinking preferences that may have been set by experiments but I'm sure there may be other things too. And if so is there a better way to handle this?

Yeah. If a profile is launched in multiple groups/multiple stores, there will be Nimbus state associated with that profile in all of those stores. Lets say a profile is launched in group A by mistake and this patch moves it back to group B. While part of group A it would enroll in experiments/rollouts, but all the state would be associated with group A and it would be lost when it launched as part of group B. This could mean that there are preferences stuck forever that Nimbus cannot reset (because it doesn't know about them).

What would you suggest we do? Leaving it in the wrong group gives a broken experience to the user and means the user will be seeing different experiment enrolments across their profiles. But changing the group potentially breaks things Nimbus previously changed.

Comment 14

[Emily McMinn :emcminn]

So if the storeID is also what gets passed as SelectableProfileService.currentProfile.id, then Messaging system is using that to identify which profile in a group to send messages to (if single profile messaging is enabled.) If that profile was previously the "messaging profile" and it gets deleted, we fall back and pick another one.

I'm assuming that moving the profile to another group would look like deletion, in which case worst case scenario is we pick a new profile to message and the user sees some messages over again, which is our normal behaviour and would be OK.

In the case of multi-profile messaging being enabled, (and a message being scoped to show in just one profile) I think we're primarily using the group ID - we store message impressions in a shared table, and we only care whether they've appeared to any profile in the group, we don't care which profile saw them. So I don't believe losing the storeID of a single profile will matter there.

I'd want to do some testing though, since I'm not sure whether the database tables make any assumptions about storeID unintentionally.

Comment 15

[Beth Rennie [:beth] (she/her)]

(In reply to Dave Townsend [:mossop] from comment #13)

(In reply to Beth Rennie [:beth] (she/her) from comment #12)

(In reply to Dave Townsend [:mossop] from comment #11)

What I want to know is how this impacts Nimbus and OMC. In some cases this profile will have run previously with one storeID and then will change to a different storeID on the next startup. Does this cause anything in the rest of the profile to now be out of sync with what is in the new store. Predominantly I am thinking preferences that may have been set by experiments but I'm sure there may be other things too. And if so is there a better way to handle this?

Yeah. If a profile is launched in multiple groups/multiple stores, there will be Nimbus state associated with that profile in all of those stores. Lets say a profile is launched in group A by mistake and this patch moves it back to group B. While part of group A it would enroll in experiments/rollouts, but all the state would be associated with group A and it would be lost when it launched as part of group B. This could mean that there are preferences stuck forever that Nimbus cannot reset (because it doesn't know about them).

What would you suggest we do? Leaving it in the wrong group gives a broken experience to the user and means the user will be seeing different experiment enrolments across their profiles. But changing the group potentially breaks things Nimbus previously changed.

From my understanding, what is happening is that a profile starts in group A, accidentally winds up in a new group B, and your patch moves it back to group A. If that is the case, the profile is already busted when it gets moved into group B because there is state from Nimbus in group A that will be overridden by Nimbus running from a blank slate in group B.

Comment 16

[Dave Townsend [:mossop]]

(In reply to Beth Rennie [:beth] (she/her) from comment #15)

(In reply to Dave Townsend [:mossop] from comment #13)

What would you suggest we do? Leaving it in the wrong group gives a broken experience to the user and means the user will be seeing different experiment enrolments across their profiles. But changing the group potentially breaks things Nimbus previously changed.

From my understanding, what is happening is that a profile starts in group A, accidentally winds up in a new group B, and your patch moves it back to group A. If that is the case, the profile is already busted when it gets moved into group B because there is state from Nimbus in group A that will be overridden by Nimbus running from a blank slate in group B.

That isn't always the case. In at least the original report in this bug the reporter manually copied their profile data into a new profile, so the profile was originally in group B but now they want it in group A. The same is true for profiles that may be migrated by the feature in bug 1996240

Comment 17

[Mihai - Alexandru Chindris]

I encountered the same store ID mismatch issue in Firefox Nightly 147.0a1 on macOS.

My symptoms were more severe than those reported originally.

Three profiles disappeared entirely from the Profile Management UI. Only an auto-generated profile remained visible. The about:profiles page showed all profiles, but they weren't in the Profile Management dropdown menu.

The root cause was that the profiles.ini file had StoreID=1194519b for all profiles, but the active profile groups database was 1f3d4e3e.sqlite, which contained only the auto-generated profile. The 1194519b.sqlite file existed, but its Profiles table was empty.

I manually fixed this issue by adding the missing profiles to the 1f3d4e3e.sqlite file and updating all the StoreID values in the profiles.ini file to 1f3d4e3e. I also updated the toolkit.profiles.storeID value in each profile's prefs.js file. This recovered all three profiles and kept all bookmarks and tabs intact.

The issue recurs after force-killing a profile too. After killing a frozen profile process, I had to fix the storeID mismatch again. The storeID for the Education profile reverted to the incorrect value (1194519b) in both profiles.ini and prefs.js.

Comment 18

[Mihai - Alexandru Chindris]

(In reply to Mihai - Alexandru Chindris from comment #17)

I encountered the same store ID mismatch issue in Firefox Nightly 147.0a1 on macOS.

My symptoms were more severe than those reported originally.

Three profiles disappeared entirely from the Profile Management UI. Only an auto-generated profile remained visible. The about:profiles page showed all profiles, but they weren't in the Profile Management dropdown menu.

The root cause was that the profiles.ini file had StoreID=1194519b for all profiles, but the active profile groups database was 1f3d4e3e.sqlite, which contained only the auto-generated profile. The 1194519b.sqlite file existed, but its Profiles table was empty.

I manually fixed this issue by adding the missing profiles to the 1f3d4e3e.sqlite file and updating all the StoreID values in the profiles.ini file to 1f3d4e3e. I also updated the toolkit.profiles.storeID value in each profile's prefs.js file. This recovered all three profiles and kept all bookmarks and tabs intact.

The issue recurs after force-killing a profile too. After killing a frozen profile process, I had to fix the storeID mismatch again. The storeID for one particular profile reverted to the incorrect value (1194519b) in both profiles.ini and prefs.js.