No more possible to populate default user profile on installation with files from "Mozilla Firefox\browser\defaults\profile"

RESOLVED WONTFIX

Status

()

Toolkit
Startup and Profile System
RESOLVED WONTFIX
2 years ago
a year ago

People

(Reporter: Arnis Rukis, Unassigned)

Tracking

({regression})

46 Branch
Unspecified
Windows
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8748113 [details]
Procmon_logs.7z - captured profile creating with FF46 and FF45

Starting first time firefox creates profile, but ignores default profile files in "C:\Program Files\Mozilla Firefox\browser\defaults\profile"

In versions until 45.0.2 this works fine.
Not working on 46.0 and later nightly builds.

Attached logs of capture of Procmon - From logs you can see that FF46 ignores and not reading content of "C:\Program Files\Mozilla Firefox\browser\defaults\profile".
I don't seem to have a browser\defaults. I do have a defaults\pref though. What are the symptoms of this bug?  (If it is that you could previously create this folder and have it applied for new profiles, I expect you will find it was known that would happen, but I've no idea what bug that might have been)
Flags: needinfo?(a.rukis)
(Reporter)

Comment 2

2 years ago
Symptoms - User profile in corporate environment not created with needed configuration: bookmarks, certificates, bokmarkstoolbar, file asociations and actions.

About usage of Browser\defaults are written in many places:
https://support.mozilla.org/en-US/questions/901549
https://support.mozilla.org/en-US/questions/1002565

Read create and test diference 45.02 and 46.0 - not working.
Flags: needinfo?(a.rukis)
You should probably use the http://mozilla.github.io/mozregression/ tool to try and work out when that change - it should be quite simple to find it with that.

Comment 4

2 years ago
Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=da327b54c78e7478f0f8072b4202f31c02f3caa1&tochange=1b47cdfb4b125dc182858c33a6a3671b13a1e51f

Regressed by bug 1234012.

Mike, do you now if its the expected behaviour after your bugfix?
I saw another report of this issue on the French board:
https://forums.mozfr.org/viewtopic.php?f=5&t=129313

Some admins use the directory \browser\defaults\profile to populate a new profile at the 1st start of Firefox (like "bookmarks.html" or "localstore.rdf").
Blocks: 1234012
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mh+mozilla)
Keywords: regression

Comment 5

2 years ago
Mike Kaply documented this procedure a few years ago:
https://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/

Comment 6

2 years ago
The new behavior is intentional. We no longer copy any files to the profile by default, but for things where defaults matter we read them the first time they are used/missing.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX

Comment 7

2 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #6)
> The new behavior is intentional. We no longer copy any files to the profile
> by default, but for things where defaults matter we read them the first time
> they are used/missing.

Can you clarify what you mean by "read them the first time"? There are settings that we want new users to have when they first launch Firefox and this is the only way that I'm aware of for doing this on user profiles where a profile doesn't already exist.
Flags: needinfo?(benjamin)

Comment 8

2 years ago
The only supported way to change any defaults is through the mechanisms provided in the distribution directory. We are explicitly trying to thwart people who attempt to change defaults in other ways because these mechanism is being abused.
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(benjamin)

Comment 9

2 years ago
This change should have been documented in release notes because it's a feature used by some admins since many years to deploy Firefox in corporate/university environment.
Keywords: dev-doc-needed

Comment 10

2 years ago
What mechanism is provided to accomplish the same behavior as was available using the \browser\defaults\profile directory?  As the others stated, we've been using this for many years in order to deploy Firefox in corporate environments.

Updated

2 years ago
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit

Comment 11

2 years ago
I agree, if the plan is to have admins use the browser/distribution directory then it should replicate the functionality of browser/defaults/profile. Then again, it's possible that it does and is just poorly documented
(Reporter)

Comment 12

2 years ago
(In reply to Loic from comment #4)
> Regression range:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=da327b54c78e7478f0f8072b4202f31c02f3caa1&tochange=1b47
> cdfb4b125dc182858c33a6a3671b13a1e51f
> 
> Regressed by bug 1234012.
> 
> Mike, do you now if its the expected behaviour after your bugfix?
> I saw another report of this issue on the French board:
> https://forums.mozfr.org/viewtopic.php?f=5&t=129313
> 
> Some admins use the directory \browser\defaults\profile to populate a new
> profile at the 1st start of Firefox (like "bookmarks.html" or
> "localstore.rdf").

Not only localstore.rdf and bookmarks.html.
We use:
Localstore.rdf - to turn on bookmarks toolbar, whitch is OFF by default.
mimetypes.rdf - to specify actions by filetypes.
Permissions.sqlite - to distribute default internal sites permissions (popup and plugin(plugin-vulnerable:npdeployjava) for example)
Places.sqlite - to distribute bookmarks in default profiles
Prefs.js - to distribute some settings to user profile
cert8.db - to distribute certificates, ok this can be done later on existing profile using certutil.
key3.db ...

Documented solution how to distribute this thing to new user profiles is needed ....
There are no mechanisms with the distribution directory for doing default profiles.

Updated

2 years ago
Duplicate of this bug: 1270665

Updated

2 years ago
Summary: Ignoring files in "C:\Program Files\Mozilla Firefox\browser\defaults\profile" → No more possible to populate default user profile on installation with files from "Mozilla Firefox\browser\defaults\profile"

Updated

2 years ago
Duplicate of this bug: 1271277

Comment 16

2 years ago
Who may expllain, what to use instead of browser\defaults\profile\ for copying cert8.db (done once per PC)?

Adjusting each user cert8.db with certutil, comparing to "defaults" way is:
- done once per user, instead of once per PC - i.e. time consuming;
- does not work at once (user starts Firefox and see ERROR - connection insecure), or requires from user to add additional step by manually adding some certificates.
- difficult (certutil, uploading certificates etc.).

Maybe firefox will start to use system certificates, just as IE and Chrome? It will simplify things.

Comment 17

2 years ago
Are developers reading these posts still?  I just want to make sure our concerns aren't going unnoticed.

Comment 18

2 years ago
To add to what post@klaban.torun.pl stated, how about at least providing us with a switch that will allow us to force Firefox to use the system certificates.

Comment 19

2 years ago
Liz, I think this change should be documented in the release notes of Firefox 46, and maybe another solution to populate a profile at the first start which was used by some admins to create a default profile for their users.
Flags: needinfo?(lhenry)
I'm investigating other solutions to this. And yes developers are listening.
Keywords: dev-doc-needed
Thanks for letting me know, Loic.  I just brought this up in a meeting. Two workarounds were suggested: using ESR45 which doesn't have these profile changes (though they will be in ESR52), and using Mike Kaply's CCK2 tool, https://mike.kaply.com/cck2/.
Flags: needinfo?(lhenry)
Duplicate of this bug: 1282005

Comment 23

2 years ago
I confirm CCK2 works as expected.
It is more complicated, than simple copy of cert8.db file, but it is possible to run CCK2:
- add some private certificates to configuration,
- export unsigned add-on,
- create account in mozilla.com and upload unsigned *.xpi there,
- then sign add-on, without publishing it, and download signed add-on *.xpi file;
- make some tests and update it, then sign again,
- and upload add-on (simple *.xpi file copy) to C:\Program Files (x86)\Mozilla Firefox\distribution\extensions\ after installatoin of Firefox

Benefits:
- one may setup https site for *.xpi file updating (in case of certificates updates)
- Firefox may update "global" list of certificates in cert8.db (old way of updatating would override it)
- there are more good settings, that may be setup in CCK2.

Comment 24

a year ago
Here's how I solved this problem for my self:

I just created a script with AutoIt its main task it is to copy first the given default profile to the users AppData dir (but only in case of no profile exists) and at the end of this it runs the original Firefox.exe.
This script is designed to replace the original Firefox.exe in order to keep the functionality of all shortcuts to Firefox.exe like the desktop shortcut...

The only thing I have to do now is to...

1. ...rename the original "Firefox.exe" included in the setup files to "Firefox-original.exe"
2. ...add my script named "Firefox.exe"
3. ...add my default profile as usual
3. ...repack the setup files to a self extracting archive with WinRAR or something else
4. ...and deploy it to our machines....


For me this was the easiest way to deal with it...
You need to log in before you can comment on or make changes to this bug.