Open Bug 1558597 Opened 5 years ago Updated 2 years ago

-CreateProfile doesn't create per-install profile

Categories

(Toolkit :: Startup and Profile System, defect, P3)

Desktop
Windows
defect

Tracking

()

People

(Reporter: gregvalure, Unassigned)

References

(Regression)

Details

(Keywords: regression)

  • Assume a clean Windows profile that does not have a Firefox profile
  • Start Firefox with -CreateProfile "[name] [path]"
  • It creates %appdata%\Mozilla\Firefox\profiles.ini plus the profile folder in %appdata%\Mozilla\Firefox\Profiles as expected
  • Start Firefox normally
  • In 66.0.4, it adopts the created profile as the default profile
  • In 67.0.1, presumably because of bug 1474285, it creates %appdata%\Mozilla\Firefox\installs.ini plus a new profile it adopts as the default and ignores the other profile, even if it was created with the same version of Firefox

I assume the -CreateProfile code needs to be updated to be aware of the changes in bug 1474285.

Use case: We use Firefox in a corporate environment. Someone logs into a computer for the first time and gets a fresh Windows profile. A login script detects this and creates a default user profile so it can add a custom user.js to it. Firefox 66.0.4 would use this profile and pick up the settings in user.js. Firefox 67.0.1 creates a separate default profile thus bypassing the settings. Maybe there are other ways of pushing out settings not covered by the group policy templates, but this is still a regression as -CreateProfile is no longer functional.

Regressed by: 1474285
Keywords: regression

Looks like CreateProfile never did set the default profile created as the default profile. It just happened by chance due to an old behaviour that isn't implemented with the new method of profile management. I'm not totally sure that making it always set the default is the right thing to do here.

Type: defect → enhancement
Priority: -- → P3

(In reply to Dave Townsend [:mossop] (he/him) from comment #1)

Looks like CreateProfile never did set the default profile created as the default profile. It just happened by chance due to an old behaviour that isn't implemented with the new method of profile management. I'm not totally sure that making it always set the default is the right thing to do here.

I would agree that if there are other profiles on the system, using -CreateProfile shouldn't change the new one to be the default. However, I would argue that if there are zero profiles on the system, using -CreateProfile to create the first one should absolutely make it the default.

Per-install profile broke the /etc/skel way to set default values. I was hoping to use -CreateProfile instead but just got hit by this bug.

It looks like the new profile should add a compatibility.ini file. I would be enough to make firefox use it in the absence of any other profile.

Has Regression Range: --- → yes
Severity: normal → S3
Type: enhancement → defect
You need to log in before you can comment on or make changes to this bug.