Creating a new profile (from the original profile), deleting that profile and then restarting Nightly does not open the original profile
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
People
(Reporter: itiel_yn8, Unassigned, NeedInfo)
References
Details
Using Windows 11, STR:
0. Use the Hebrew localized version of Nightly. This could be an important step, could be not. More details below
- Use the original profile, and create a new profile
- Delete that new profile from the initial about:editprofile window
- Restart Nightly (in my case I did about:crashparent, not sure if this part is important)
AR:
After re-launching Nightly, a new profile is opened, with seemingly no user-visible option of going back to the original profile.
The original profile is not seen in the Profiles submenu in the app menu, nor in about:profiles, nor when launching Nightly via firefox.exe -p.
I had to mess around with profiles.ini to get my original profile to launch.
ER:
Original profile should be used after the restart.
This is something that I assume UX and the devs haven't encountered, and so if you can't manage to reproduce the STR above normally, the only differentiator could be the initial profile name/path -- that is localized (Profile = פרופיל) and could potentially cause issues.
Hence if you can't reproduce this normally, try to use the Hebrew localized version of Nightly (using intl.l10n.pseudo = bidi won't cut it I think).
|
||
Comment 1•1 year ago
|
||
The severity field is not set for this bug.
:mossop, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 2•1 year ago
|
||
This would leave a user in a very broken state but I'm not sure how it could be happening.
(In reply to Itiel from comment #0)
Using Windows 11, STR:
0. Use the Hebrew localized version of Nightly. This could be an important step, could be not. More details below
- Use the original profile, and create a new profile
- Delete that new profile from the initial about:editprofile window
Did you mean about:newprofile? That is what we normally open for editing new profiles.
(In reply to Dave Townsend [:mossop] from comment #2)
Did you mean about:newprofile? That is what we normally open for editing new profiles.
I think so, but now that I'm trying to re-reproduce it to confirm, the new profile doesn't get created to begin with, and I'm getting the following errors on the browser console when trying to click the New Profile button from the Profiles submenu:
Uncaught (in promise) TypeError: can't access property "id", SelectableProfileService.currentProfile is null
populateSubView chrome://browser/content/browser-profiles.js:333
browser-profiles.js:333:26
Error: Unknown preference 'datareporting.dau.cachedUsageProfileGroupID' SelectableProfileService.sys.mjs:1588:13
Not sure if this is related to me trying to fix the previous issue by touching profiles.ini, or if this is unrelated...
The contents of profiles.ini if this matters:
[General]
StartWithLastProfile=1
Version=2
[Profile0]
Name=default-nightly
IsRelative=1
Path=Profiles/o4ls1c50.default-nightly-1579068187930
Default=1
StoreID=83d1efd2
ShowSelector=0
[Install6F193CCC56814779]
Default=Profiles/o4ls1c50.default-nightly-1579068187930
Locked=1
[BackgroundTasksProfiles]
MozillaBackgroundTask-6F193CCC56814779-defaultagent=zdvnkyd6.MozillaBackgroundTask-6F193CCC56814779-defaultagent
Suggestions? :(
I'm on latest Nightly.
|
|
||
Comment 4•1 year ago
|
||
(In reply to Itiel from comment #3)
(In reply to Dave Townsend [:mossop] from comment #2)
Did you mean about:newprofile? That is what we normally open for editing new profiles.
I think so, but now that I'm trying to re-reproduce it to confirm, the new profile doesn't get created to begin with, and I'm getting the following errors on the browser console when trying to click the New Profile button from the Profiles submenu:
Uncaught (in promise) TypeError: can't access property "id", SelectableProfileService.currentProfile is null populateSubView chrome://browser/content/browser-profiles.js:333 browser-profiles.js:333:26 Error: Unknown preference 'datareporting.dau.cachedUsageProfileGroupID' SelectableProfileService.sys.mjs:1588:13Not sure if this is related to me trying to fix the previous issue by touching profiles.ini, or if this is unrelated...
I'm guessing when you manually edited profiles.ini you changed the path but not the storeid which probably leaves us in a state where the store doesn't contain your current profile. We really need to be more resilient to that. Assuming you had no other profiles anyway you can reset the pref toolkit.profiles.storeID and delete the storeid line from profiles.ini and I think we will create a new store on next startup.
Done that, but now the error message has changed to the following:
Error: Unknown preference 'datareporting.dau.cachedUsageProfileGroupID' SelectableProfileService.sys.mjs:1588:13
That pref does, in fact, exist. Resetting it and restarting Nightly doesn't help here.
Current profiles.ini:
[Install6F193CCC56814779]
Default=Profiles/o4ls1c50.default-nightly-1579068187930
Locked=1
[Profile0]
Name=default-nightly
IsRelative=1
Path=Profiles/o4ls1c50.default-nightly-1579068187930
Default=1
ShowSelector=0
StoreID=2c5e536b
[General]
StartWithLastProfile=1
Version=2
[BackgroundTasksProfiles]
MozillaBackgroundTask-6F193CCC56814779-defaultagent=zdvnkyd6.MozillaBackgroundTask-6F193CCC56814779-defaultagent
|
|
||
Comment 6•1 year ago
|
||
I suspect this is because the pref isn't in the database and we attempt to retrieve it when creating a new profile. We should be adding it on startup though. Niklas, do you have any ideas how to get out of this mess?
I've filed bug 1991913 to look into the general issue of being more tolerant when we end up in odd states.
|
||
Comment 7•1 year ago
|
||
Manually editing the datareporting.dau.cachedUsageProfileGroupID pref in about:config will add it to the db because we have an observer for the pref.
Copy the original pref value, then set the pref to FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF and then set it back to the original value.
I just tried this on my machine and it successfully added the pref to the db.
This didn't work for me. Or rather, didn't fix the issue at hand.
Just to clarify, are these the only steps needed? No restart in-between? (I've done that as well, but maybe I'm missing a crucial step somewhere)
|
|
||
Comment 9•1 year ago
|
||
Ahh, I'm assuming datareporting.dau.cachedUsageProfileGroupID isn't being observed.
You should be able to just call await SelectableProfileService.trackPref("datareporting.dau.cachedUsageProfileGroupID") and that should add it to the db. You can check that the pref is in the db by
await SelectableProfileService.getDBPref("datareporting.dau.cachedUsageProfileGroupID") and it should return the value
|
Reporter | |
Comment 10•1 year ago
|
||
Thanks Niklas, that did the trick!
:mossop, now that I re-read the bug report above, I realize I forgot to mention some critical info- deleting the profile in step 2 (and yes, that's from about:newprofile as you said), deletes the profile and closes it, but then immediately creates a new one. And that cycle doesn't end (deleting the profile > a new profile gets created automatically > ...).
However.. now that I try this a 3rd time, a new profile doesn't get re-created, but I'm still being left in a broken state.
Doing a about:restartrequired boots me in my profile, but about:profiles lists only the newly created profile. Closing Nightly and then re-opening it will then boot into the new profile that I've supposedly deleted already =\
Description
•