Windows Firefox 67: profile not loaded when Firefox is opened resulting in new installation ID (related to upper-lower case)
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
People
(Reporter: cybermcm, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
Windows 1903: I have a profile directory which is specified with an absolute path (e.g. c:\profiles\ff)
Profile directory is specified in C:\Users\xxx\AppData\Roaming\Mozilla\Firefox\profiles.ini
Now I want to start firefox with an URL, e.g. firefox.exe https://cnn.com
Actual results:
Firefox opens but creates a complete new profile
Expected results:
Firefox should be opened with the default profile.
This happens since I upgraded to Windows 1903. It works with Windows 1809.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
Please attach a copy of profiles.ini. Have you done any manual modification of the file?
I think that I initially created the ini file a long time ago, currently:
[Install9F049047DC020C2B]
Default=C:\SYSTEM\files\configs\Firefox_Profiles\enterprise
Locked=1
[Profile0]
Name=default
IsRelative=0
Path=C:\SYSTEM\files\configs\Firefox_Profiles\enterprise
Default=1
[General]
StartWithLastProfile=1
Version=2
As a workaround I'm starting Firefox this way:
firefox.exe -P "default" https://cnn.com
This way no new profile is created
|
|
||
Comment 3•5 years ago
|
||
I assume you have already removed the new profile that gets created. Can you attach a copy of profiles.ini immediately after you start Firefox with a url and the new profile is created?
new profiles.ini:
[Install9F049047DC020C2B]
Default=C:\SYSTEM\files\configs\Firefox_Profiles\enterprise
Locked=1
[Profile1]
Name=default-release
IsRelative=1
Path=Profiles/4j1xm4dc.default-release
[Profile0]
Name=default
IsRelative=0
Path=C:\SYSTEM\files\configs\Firefox_Profiles\enterprise
Default=1
[General]
StartWithLastProfile=1
Version=2
[InstallC0814E5C762A2949]
Default=Profiles/4j1xm4dc.default-release
Locked=1
I noticed that this happens if firefox is called from another path, e.g. c:\system\bin\firefox\firefox.exe outlook.com, then the new profile is created.
If I cd into the path and start firefox within the path it works
e.g. cd c:\system\bin\firefox\ -> firefox.exe outlook.com -> no new profile is created
|
|
||
Comment 5•5 years ago
|
||
The issue here is that you're running two different Firefox installs. It is intentional that they now run with different profiles.
I don't understand. I have only one portable firefox located in c:\system\bin\firefox.
It behaves different if started with c:\system\bin\firefox\firefox.exe outlook.com or started with cd c:\system\bin\firefox\ -> firefox.exe outlook.com
This wasn't an issue until recently....
|
|
||
Comment 7•5 years ago
|
||
Could be something unique to the portable firefox, (where did it come from?) but your profiles.ini is listing two different installs of Firefox.
Firefox was downloaded from http://ftp.mozilla.org/pub/firefox/, that was months ago. I switched from beta to stable, now I'm on 67.0.
This behavior started with my Windows upgrade to 1903.
|
|
||
Comment 9•5 years ago
|
||
(In reply to Markus from comment #8)
Firefox was downloaded from http://ftp.mozilla.org/pub/firefox/, that was months ago. I switched from beta to stable, now I'm on 67.0.
Ah we have different definitions for "portable".
This behavior started with my Windows upgrade to 1903.
Are you positive it was that and not the update to Firefox 67?
If you open cmd and do "cd c:\system\bin\firefox" what does the command prompt (the bit before the cursor) now show?
|
Reporter | |
Comment 10•5 years ago
|
||
I've done some additional testing and you are right. It is related to FF 67 and not to WIndows (changed the bug title).
Well start again:
I have a profile stored in an absolute directory.
FF <67: starting FF: profile path is taken from profiles.ini -> OK
FF 67: starting FF: FF creates a new profile, claiming that this is a new installation, creating a new profile and installation ID
FF 67: starting FF; with "-P default", FF is using the existing (only one) profile, no new installation ID is created
Currently not sure if this is a bug or some sort of desired behavior?
|
|
||
Comment 11•5 years ago
|
||
(In reply to Markus from comment #10)
I've done some additional testing and you are right. It is related to FF 67 and not to WIndows (changed the bug title).
Well start again:
I have a profile stored in an absolute directory.FF <67: starting FF: profile path is taken from profiles.ini -> OK
FF 67: starting FF: FF creates a new profile, claiming that this is a new installation, creating a new profile and installation ID
FF 67: starting FF; with "-P default", FF is using the existing (only one) profile, no new installation ID is createdCurrently not sure if this is a bug or some sort of desired behavior?
It depends, was the <67 Firefox in a different installation directory to the 67 version?
|
|
Reporter | |
Comment 12•5 years ago
|
||
directory was the same.
FF <67 doesn't care as long as profiles.ini is stored in the user profile
|
|
||
Comment 13•5 years ago
|
||
If you open cmd and do "cd c:\system\bin\firefox" what does the command prompt (the bit before the cursor) now show?
|
|
Reporter | |
Comment 14•5 years ago
|
||
not quite sure if this is the answer to your question:
c:\Temp>cd c:\system\bin\firefox
c:\SYSTEM\bin\Firefox>
|
|
||
Comment 15•5 years ago
|
||
Ok the issue you describe in comment 6 is bug 1555319. It's possible that that may be your entire issue.
|
|
Reporter | |
Comment 16•5 years ago
|
||
You nailed it, this is my issue!
I'm sometimes calling FF via script (with predefined URLs). The script doesn't exactly match the upper-lowercase situation on my drive.
I changed upper-lowercase in my script to be exactly as shown on the command line -> now no new profile gets created.
A nasty bug for Windows users ;-)
As far as I can follow the bug was addressed in the installer script but will still be there if called from an external source (like a script in my case)...
|
|
||
Comment 17•5 years ago
|
||
Alright I'm just going to duplicate this over to bug 1555319 for now.
Description
•