Closed Bug 1910062 Opened 3 months ago Closed 2 months ago

Setting "MOZ_LEGACY_PROFILES" forces switch from ESR- to default-profile when using Firefox ESR 115.13.0

Categories

(Firefox :: Enterprise Policies, defect)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: pascal.michaelis, Unassigned)

Details

Steps to reproduce:

for verification I set up a clean Win10 Pro (22H2) VM > installed Firefox ESR 115.13.0 > opened it > set a bookmark > two profiles are automatically created (default and default-esr; default-esr is used) > set a system wide environment variable "MOZ_LEGACY_PROFILES" > reboot the VM > opened Firefox again

Actual results:

the used Firefox-profile switched from default-esr to default > previously set profile settings are gone

Expected results:

keep the default-esr Firefox-profile

(background: intended enterprise-wide ESR upgrade from ESR 115x86 to ESR 128x64 through MECM)

the same behavior could be verified for Firefox ESR 128.0

The Bugbug bot thinks this bug should belong to the 'Firefox::Shell Integration' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Shell Integration
Component: Shell Integration → Enterprise Policies

Mossop:

Any thoughts here?

I don't understand why it would switch profiles.

It should always use the last profile, shouldn't it if LegacyProfiles is set?

In hindsight, the correct solution is to have set LegacyProfiles from the beginning and then you would have never gotten the dual profiles.

Flags: needinfo?(dtownsend)

(In reply to Mike Kaply [:mkaply] from comment #3)

Mossop:

Any thoughts here?

I don't understand why it would switch profiles.

It should always use the last profile, shouldn't it if LegacyProfiles is set?

No. Setting legacy profiles switches to the old method of profile selection which selects the one with Default=1 in the ini file, which would be default in this case (created for backwards compatibility with older versions of Firefox).

In hindsight, the correct solution is to have set LegacyProfiles from the beginning and then you would have never gotten the dual profiles.

Yes, switching that flag on and off will likely cause changes to the profile selected by default. It's possible to make it work right (setting that Default=1 flag on the default-esr profile) but I would say that switching to legacy profiles after you've already been using Firefox is mostly unsupported.

Flags: needinfo?(dtownsend)

The problem is that with or without "LegacyProfiles" there is a switch in the used Firefox-profile because of the new program path when deploying the x64 version. Setting the environment variable was a test to handle this problem.
So if I got it right there is no way switching from x86 to x64 without forcing the user to use a new profile if "LegacyProfiles" was not set right from the get go when deploying the first x86 versions some 20+ years ago?
Editing the profiles.ini is no solution because the only way to automate this would be with the help of MS Active Setup and this would require a fresh logon after installation.

In the past, most folks just decided to put the 64 bit version into Program Files (x86) (which will happen by default since Firefox tries to use the same directory as before).

There's no technical reason to put the 64 bit version in Program Files.

well that seems to be the culprit then. The default behavior of the new ESR 128.0 x64 is to be installed parallel to the x86 version of ESR 115(.13.0).
I've crosschecked this in a fresh, plain Win Pro 22H2 VM.

I've confirmed what you are seeing and I'm going to open a bug.

Do you have the ability to invoke the MSI file with parameters to specify the install directory?

https://support.mozilla.org/en-US/kb/deploy-firefox-msi-installers

I'm going to close this bug as WONTFIX as I don't think we would accept a patch that solves the originally reported issue of the default profile changing when setting MOZ_LEGACY_PROFILES. Changing the default when changing the install directory is also expected so bug 1910964 is the correct fix for your issue.

Status: UNCONFIRMED → RESOLVED
Closed: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.