Profile manager fails to open non-default profile because profiles.ini is read-only.
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
People
(Reporter: limerator+bugzilla, Unassigned)
Details
Attachments
(1 file)
|
5.21 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Prerequisites:
- have several Firefox profiles
- "StartWithLastProfile=0" in profiles.ini
- set one profile as default ("Default=1")
- make your profiles.ini readonly so the default profile isn't changed just like that by firefox
- use firefox 68.2.0esr
Steps to reproduce:
- start FF with "...\firefox.exe" or "...\firefox.exe -no-remote -ProfileManager".
- the profile manager shows up with a preselected profile choice.
- select another profile and "Start Firefox".
.... - Chose "Restart Firefox".
- Wait for FF to do whatever in the background until the profile manager shows up again.
- Start the profile chosen in 3. (it's the preselected profile now) by "Start Firefox".
Actual results:
after 3. an error box appears (see attached image):
Title - Changes not saved
Content - An unexpected error has prevented your changes from being saved.
Options - "Restart FF" or "Exit"
and after 6. the profile manager restarts without doing anything else, it just returns to 5.
Expected results:
after 3. the selected profile should start in a new FF instance.
It may display an error message or warning but shouldn't just fail completely.
Said error message should allow the user to ignore a read-only profiles.ini.
It would be even better if the profile manager just had another check box to not change the default profile no matter which one it is and which other profile I chose to use right now. I wouldn't need to make my profiles.ini read-only in that case.
And starting an endless loop of fail after 6. is never a good outcome...
Comment 1•6 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
forgot a few details.
This only became a problem/bug after the last FF esr update. Prior versions to FF 68.2.0esr just ignored the read-only state of the profiles.ini and started without a hitch.
I was using this setup for years without any issues.
It may be related to 304911 and as i just found 1554252.
I probably saw both bug's titles when creating this one but they seemed irrelevant/unrelated to me because I can start my FF profiles.
My handicapped workaround is closing/exiting the profile manager after the error message and starting it again. It works on the second try.
Comment 3•6 years ago
|
||
Probably related to the per-install profile feature (bug 1474285)? It needs to write info in profiles.ini.
https://support.mozilla.org/en-US/kb/dedicated-profiles-firefox-installation
Does it work if launched with --allow-downgrade?
Updated•6 years ago
|
Comment 4•6 years ago
|
||
The problem is that you're trying to change the profile to use, but you've made it impossible for Firefox to save that change.
(In reply to Dave Townsend [:mossop] (he/him) from comment #4)
The problem is that you're trying to change the profile to use, but you've made it impossible for Firefox to save that change.
*** This bug has been marked as a duplicate of bug 1554252 ***
I'm not trying to change anything. I just have a default profile and don't care about the last used profile. But I use 3-5 different profiles at the same time (one primary and the others as no-remote) and I select and start them with the profile manager.
It's just that Firefox is intentionally mixing up what a default profile and the last used one actually is, which forced me to make my profiles.ini read-only years ago.
And now after >5 years of working perfectly the pmanger suddenly needs to write to the profiles.ini or it just fails? If that is not a bug what is?
I would love to make my profiles.ini writeable but FF always sets the last used one as default and i don't want that. And creating ~10 different FF .lnks for all my seven (7) different profiles in several locations is impractical (~10 because the non-no-remote one changes sometimes).
The profile manager even has the option to "use the selected profile without asking at startup"[1] why not just add another checkbox "set the select profile as default profile"?
Actually why does the Pmanager even change the default profile when the ->[1] checkbox is not checked?
When used with the -no-remote argument it makes even less sense to change the default profile (imho).
From a structure/flow/logic point of view none of the three points make sense the way it is right now. Should I report those behaviors as bugs?
Ignoring all that ^^ the behavior of the profile manager is still buggy with the infinite loop between 4. and 6. - no proper error message just failing silently.
(In reply to Francesco Lodolo [:flod] (PTO Oct 25-30) from comment #3)
Probably related to the per-install profile feature (bug 1474285)? It needs to write info in profiles.ini.
https://support.mozilla.org/en-US/kb/dedicated-profiles-firefox-installationDoes it work if launched with
--allow-downgrade?
Just tried that and it makes no difference at all. I'm only using one FF version just in several instances with different profiles for specific tasks/ purposes at the same time (sometimes even distributed between two different Windows user accounts who of course have full access to all profile folders and use the same profiles.ini).
Description
•