1571662 - Firefox 67+ does not honor profiles.ini

Status: RESOLVED INVALID

(Toolkit :: Startup and Profile System, defect)

Description

[mark]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.145 Safari/537.36 Vivaldi/2.6.1566.49

Steps to reproduce:

We're now using Firefox for years and years at our corporation.
In the past Firefox was lacking the possibility to be managed by Windows Group policies, we used a combination of override.ini, mozilla.cfg, local-settings.js, profiles.ini and later also policies.json.
Although configuration was fragmented over several files, it gave us fine grained control, and in the end it did exactly what we wanted and needed.

profiles.ini setup like this:
[General]
StartWithLastProfile=1
[Profile0]
Name=User
IsRelative=0
Path=h:\FireFox
Default=1

override.ini loogs like this
[XRE]
EnableProfileMigrator=false

h:\Firefox is their own personal windows networkdrive.

This always resulted in 0-hassle experience for our users. New users didn't have to do anything and had their profile created on the right place automatically. From then on, on every domain computer or VDI instance they logged on they had their own firefox profile.

This doesn't work anymore on firefox 67+, so we are still on version 66.0.5.

I know that there are changes made to how Firefox used profiles in relation to installation path, witch is really a unorthodox way of doing things as it really kills the possibility of using virtual application repackagers like App-V.

But this conflicts with documentation found online: http://kb.mozillazine.org/Profiles.ini_file
I do not want Firefox to create a profile somewhere. I want it to create in in h:\Firefox and always use it. That's what profiles.ini should do, but it doens't.

Also, I can hardly find anything on this new file installs.ini .

Actual results:

• Firefox creates profile in the wrong location.
• Firefox does not really use the last profile as stated in profiles.ini but also creates a new one in the user profile. User in then able to switch it(again: should not be necessarily), but has to do this every time he/she logs in. This probably due to installation path differences due to App-V.

Expected results:

Honor profiles.ini settings.

Comment 1

[mark]

Just did some further testing. The problem occurs when repackaging Firefox 67+(also ESR release 68.01) with microsoft App-V. FYI: Although I installed Firefox in "c:\Program Files\Mozilla Firefox" , it isn't really loaded from there at a client computer, but from virtual file system.
The Firefox installation directory/seperate profile weirdness(sorry, have to be frank) breaks profiles.ini. After several launches with different versions of repackaged firefox installations I have multiple profiles(named Default, default-release, default-esr, default-esr-1, etc..), but the profile in h:\Firefox isn't used or visible in about:profiles although stated in profile.ini .
When I delete all the profiles, including the one in in h:\firefox and delete all windows profile settings it will create a new profile in h:\Firefox. But when using another computer, it will not use the profile in h:\Firefox and it starts creating profiles in the user profile again.

I also can not determine where firefox itself "thinks" it is installed. Even in about:support there is no mention of the installation directory.

It's seems fine with local installations though, but most larger company's will use app virtualization for deployments and will probably have similar issues i expect.

SO... newer Firefox versions are not compatible anymore with virtual application containers.
Please consider a option to disable the "automatic user profile creation based on firefox installation path" so that profiles.ini does work as expected.

Comment 2

[Dave Townsend [:mossop]]

The format of profiles.ini has changed so what you're seeing is intentional. Depending on the outcome bug 1572789 might help with what you're looking for.