85.28 KB, application/x-7z-compressed
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)
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.
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.
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").
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mike Kaply documented this procedure a few years ago: https://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/
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
(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.
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.
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.
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.
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
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
(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.
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"
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.
Are developers reading these posts still? I just want to make sure our concerns aren't going unnoticed.
To add to what firstname.lastname@example.org stated, how about at least providing us with a switch that will allow us to force Firefox to use the system certificates.
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.
I'm investigating other solutions to this. And yes developers are listening.
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/.
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.
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.