Open Bug 1572789 Opened 3 years ago Updated 2 years ago

Allow using empty profiles on first run of a profile-per-install build.

Categories

(Toolkit :: Startup and Profile System, enhancement, P2)

enhancement

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix

People

(Reporter: mkaply, Unassigned)

Details

(Keywords: regression, Whiteboard: [no-nag])

On a machine with no Firefox profile information, run the following command with the Firefox 68 ESR:

firefox.exe -CreateProfile default

Then start the Firefox ESR.

It creates a second profile called "default-esr" and uses that.

Since there is only one profile, it should have been used. It should not have created a new profile.

Flags: needinfo?(dtownsend)

I just experienced something similar on release. I only had one profile called default (old with an older version of Firefox).

When I started Firefox after it upgraded, it created a new profile called default-release and moved all the files from my default profile (except for times.json) into that new profile and now have two profiles.

Even worse, for some reason, the old default profile is marked as the default profile for some reason. And even though that profile is marked as default and it is set to start with the last profile, it's starting with default-release?

Here are the contents of profiles.ini

[Install308046B0AF4A39CB]
Default=Profiles/exkpc2id.default-release
Locked=1
​
[Profile1]
Name=default
IsRelative=1
Path=Profiles/8l1s2xdg.default
Default=1
​
[Profile0]
Name=default-release
IsRelative=1
Path=Profiles/exkpc2id.default-release
​
[General]
StartWithLastProfile=1
Version=2

Even on a brand new install of Firefox, I end up with default and default-release profiles. Something's wrong...

This is intentional with the new profile handling. Would it make sense for -createprofile to also accept an additional argument to make the newly created profile the default profile?

Flags: needinfo?(dtownsend) → needinfo?(mozilla)

This is intentional with the new profile handling.

Why don't we just use the existing profile if there is only one? Why do we rename it (and keep the old one around)

Flags: needinfo?(mozilla)

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

This is intentional with the new profile handling.

Why don't we just use the existing profile if there is only one? Why do we rename it (and keep the old one around)

We shouldn't be renaming it. On startup we mark the only profile as the default for older versions of Firefox and create a new profile because we don't want to use the same profile as those older versions do.

On startup we mark the only profile as the default for older versions of Firefox and create a new profile because we don't want to use the same profile as those older versions do.

But there's only one Firefox and one profile? I guess I'm missing something here. I would never expect Firefox to create a new profile if I already have one and I'm using the same version of Firefox that I created the profile with (ESR case).

And I would also never expect a new profile if I'm going from 60 to 68 because again, I only have one profile, so why would a new one get created? We should just use the new profile without moving it (Note that as far as the older profile goes, there's no content in it. We make a new directory called default-release, we move all the files there and start using it.)

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

On startup we mark the only profile as the default for older versions of Firefox and create a new profile because we don't want to use the same profile as those older versions do.

But there's only one Firefox and one profile? I guess I'm missing something here. I would never expect Firefox to create a new profile if I already have one and I'm using the same version of Firefox that I created the profile with (ESR case).

We don't know that there isn't another Firefox, and regardless if there isn't one now the user may install one later.

If we don't create a new profile for use then should an older version of Firefox be installed it would start sharing the profile with ESR.

And I would also never expect a new profile if I'm going from 60 to 68 because again, I only have one profile, so why would a new one get created?

But that isn't what is happening here. We do expect a new profile when moving from 68 to 60 which is what this is handling.

We should just use the new profile without moving it (Note that as far as the older profile goes, there's no content in it. We make a new directory called default-release, we move all the files there and start using it.)

What files are you seeing be moved? I'm not aware of any code that moves files here.

I guess an alternative would be to use the single profile and then create a second profile that older versions could use as their default if started.

For reference: My Bug

This behavior of creating two profiles(also not honoring profiles.ini settings) really does not play nice with our corporate environment, and I expect with many other corporate environments where they just want to create a profile in a "set" location.
Of all the documentation I found online of profiles and profiles.ini, I can not find reference to the fact that it now just creates a profile somewhere in the user profile, and uses it at first launch regardless what you have set in profiles.ini or which environment variables you have set.

As I'm a fan of Firefox, I want to take the time and find a solution for this, but I'm pretty sure most admins at most company's would have switched to Chrome 10x already.

And of course I have no say in this, nor should you value my opinion, but for who is this feature(Profile per installation location) meant?
I'm sure 99.9% of users do not care about multiple profiles and/or multiple Firefox installations, versions and or development branches.

Feel free to delete this comment if it does not add anything substantial to the discussion.

(In reply to mark from comment #8)

For reference: My Bug

This behavior of creating two profiles(also not honoring profiles.ini settings) really does not play nice with our corporate environment, and I expect with many other corporate environments where they just want to create a profile in a "set" location.
Of all the documentation I found online of profiles and profiles.ini, I can not find reference to the fact that it now just creates a profile somewhere in the user profile, and uses it at first launch regardless what you have set in profiles.ini or which environment variables you have set.

This isn't the case, if a profile is correctly defined in profiles.ini and assigned as the default for firefox (the mechansim for doing so changed in 67) then no new profile gets created. That profiles.ini is not documented is sort of intentional, I do not want to encourage manually editing profiles.ini as various mistakes can cause problems that Firefox cannot correct for. I would much prefer to add mechanisms built into Firefox to do any necessary modification as those can be kept up to date if the format of profiles.ini changes over time.

Chiming here too...

Im seeing this behavior on Firefox ESR 68.0.1 on macOS 10.14 Mojave.

User can see (2) profiles in the about:profiles UI.

I discovered this testing the deployment of ESR 68.0.1 (using configuration profiles) on Macs with existing installations of ESR 52 (using CCK2/autoconfig).

Like everyone else here, my goal is to deploy ESR 68 onto ESR 52 silently without confusion (i.e.; minimal impact to user's bookmarks, etc).

My options are:

-Wait for ESR 69?
-Deploy ESR 68+ using CCK2 one last time before fully leveraging new method of configuration profiles?
-Determine what workarounds/hacks we can use to 'limp along' with ESR 68?

  • Other?

My thanks to Mike for working on profiles. Profiles will be a great deployment/management option once its solid. CCK2 worked fine for me but took extra work and didn't fully follow the standard method I use for other macOS apps (Jamf configuration profiles).

The priority flag is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)
Flags: needinfo?(dtownsend)
Priority: -- → P2
Type: defect → enhancement
Summary: Firefox ESR doesn't honor default profile and creates a new one → Allow using empty profiles on first run of a profile-per-install build.
Type: enhancement → defect
Type: defect → enhancement
Type: enhancement → defect
Type: defect → enhancement
Whiteboard: [no-nag]
You need to log in before you can comment on or make changes to this bug.