Last Comment Bug 1234012 - Figure out what to do about the default profile
: Figure out what to do about the default profile
Status: RESOLVED FIXED
:
Product: Toolkit
Classification: Components
Component: Startup and Profile System (show other bugs)
: unspecified
: Unspecified Unspecified
-- normal with 1 vote (vote)
: mozilla46
Assigned To: Mike Hommey [:glandium]
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
Depends on: 1269706
Blocks: 1238428
  Show dependency treegraph
 
Reported: 2015-12-19 15:55 PST by Mike Hommey [:glandium]
Modified: 2017-02-01 03:49 PST (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
Part 1 - Remove {localstore,mimeTypes}.rdf, user{Chrome,Content}-example.css (19.26 KB, patch)
2015-12-24 15:44 PST, Mike Hommey [:glandium]
benjamin: review+
Details | Diff | Splinter Review
Part 2 - Do not try to copy files from the non-existing default profile (8.65 KB, patch)
2015-12-24 15:44 PST, Mike Hommey [:glandium]
benjamin: review+
Details | Diff | Splinter Review
Part 3 - Remove the NS_APP_PROFILE_DEFAULTS_{NLOC_,}50_DIR directory keys (10.51 KB, patch)
2015-12-24 15:44 PST, Mike Hommey [:glandium]
benjamin: review+
Details | Diff | Splinter Review
Bonus - Remove defaults/profile/bookmarks.html from b2gdroid, b2g, and android package manifests (2.59 KB, patch)
2015-12-24 16:22 PST, Mike Hommey [:glandium]
benjamin: review+
Details | Diff | Splinter Review

Description User image Mike Hommey [:glandium] 2015-12-19 15:55:41 PST
When creating a new profile, the profile service copies files from NS_APP_PROFILE_DEFAULTS_50_DIR in the newly created user profile directory. The catch is that NS_APP_PROFILE_DEFAULTS_50_DIR is the "defaults/profile" directory in the Application directory, which, as of Firefox 4.0, doesn't exist because it's all in the omnijar.

This means newly create profiles currently don't receive localstore.rdf, mimeTypes.rdf chrome/userChrome-example.css chrome/userContent-example.css or the default prefs.js.

The latter is not a problem because it's empty anyways, and the first two are not a problem because they are placeholders and we deal with them not existing.

There is also a bookmarks.html file, but I think the code in nsBrowserGlue.js takes care of importing it through a resource:// url.

So that really leaves chrome/userChrome-example.css and chrome/userContent-example.css not being copied, and IMHO, we can live without (and obviously, users have lived without for several years now).

Note that the interesting corollary is that if you build Firefox with the flat or jar format instead of omnijar, then you currently get the pre-4.0 behavior of copying the default profile files.

Now, that raises several questions:
- Should we move the default profile data outside omnijar? (the above would make the answer to this "no")

- Should we remove those files from the tree entirely? There is at least no point copying them into Firefox if they're never going to be used.

- What about non-Firefox?

- Does it make sense to keep the Profile Service code that handles copying the default profile if there is, in practice, no default profile?

- Does it make sense to keep all the default profile related File Location Provider keys? (there are multiple keys inheriting from NS_APP_PROFILE_DEFAULTS_50_DIR)
Comment 1 User image Benjamin Smedberg [:bsmedberg] 2015-12-22 08:56:07 PST
A. New profiles should always be blank directories and we should not do any file copying.
B. Because of that we should remove the template files from the tree that aren't needed.
C. I'm less sure about the PROFILE_DEFAULTS stuff: is that still used by the code for default bookmarks and whatnot?
Comment 2 User image Mike Hommey [:glandium] 2015-12-22 13:34:19 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> C. I'm less sure about the PROFILE_DEFAULTS stuff: is that still used by the
> code for default bookmarks and whatnot?

AFAICT, and as mentioned in comment 0, the code that I think is for default bookmarks is using resource:///defaults/profile/bookmarks.html, which properly goes into the omnijar to read it, and is clearly not NS_APP_PROFILE_DEFAULTS_50_DIR. There may be other things that use it, I'll poke around.

Will at least do A and B.
Comment 3 User image Mike Hommey [:glandium] 2015-12-24 15:44:12 PST
Created attachment 8701880 [details] [diff] [review]
Part 1 - Remove {localstore,mimeTypes}.rdf, user{Chrome,Content}-example.css
Comment 4 User image Mike Hommey [:glandium] 2015-12-24 15:44:31 PST
Created attachment 8701881 [details] [diff] [review]
Part 2 - Do not try to copy files from the non-existing default profile
Comment 5 User image Mike Hommey [:glandium] 2015-12-24 15:44:55 PST
Created attachment 8701882 [details] [diff] [review]
Part 3 - Remove the NS_APP_PROFILE_DEFAULTS_{NLOC_,}50_DIR directory keys
Comment 6 User image Mike Hommey [:glandium] 2015-12-24 16:22:42 PST
Created attachment 8701891 [details] [diff] [review]
Bonus - Remove defaults/profile/bookmarks.html from b2gdroid, b2g, and android package manifests

Since part 1 touches close to this, I figured I'd just do it here instead of a separate bug for 3 lines.
Comment 7 User image Philip Chee 2015-12-31 07:33:50 PST
(In reply to Mike Hommey [:glandium] (VAC: 31 Dec - 11 Jan) from comment #0)

> This means newly create profiles currently don't receive localstore.rdf,
> mimeTypes.rdf chrome/userChrome-example.css chrome/userContent-example.css
> or the default prefs.js.
In SeaMonkey we moved all these files outside the omnijar.

> The latter is not a problem because it's empty anyways, and the first two
> are not a problem because they are placeholders and we deal with them not
> existing.

> There is also a bookmarks.html file, but I think the code in
> nsBrowserGlue.js takes care of importing it through a resource:// url.
Our bookmarks.html lives in the omnijar. Something copies it to new profiles.

> So that really leaves chrome/userChrome-example.css and
> chrome/userContent-example.css not being copied, and IMHO, we can live
> without (and obviously, users have lived without for several years now).

We want the user*-example.css. Examples on the internet refer to these files.

> Note that the interesting corollary is that if you build Firefox with the
> flat or jar format instead of omnijar, then you currently get the pre-4.0
> behavior of copying the default profile files.
> 
> Now, that raises several questions:
> - Should we move the default profile data outside omnijar? (the above would
> make the answer to this "no")

> - Should we remove those files from the tree entirely? There is at least no
> point copying them into Firefox if they're never going to be used.
> 
> - What about non-Firefox?
SeaMonkey does use them.

> - Does it make sense to keep the Profile Service code that handles copying
> the default profile if there is, in practice, no default profile?
> 
> - Does it make sense to keep all the default profile related File Location
> Provider keys? (there are multiple keys inheriting from
> NS_APP_PROFILE_DEFAULTS_50_DIR)
SeaMonkey does use that
Comment 8 User image Philip Chee 2015-12-31 07:42:16 PST
(In reply to Mike Hommey [:glandium] (VAC: 31 Dec - 11 Jan) from comment #5)
> Created attachment 8701882 [details] [diff] [review]
> Part 3 - Remove the NS_APP_PROFILE_DEFAULTS_{NLOC_,}50_DIR directory keys

> Nothing apart the code that was just removed uses those keys, so remove them.
> Actually, there is a use in Seamonkey, but considering they're shipping with
> omnijar, the code expecting the directory has not been working as designed for
> a while, so they can fixup and remove that use as well.
The code is currently working because we moved those files out of the omnijar back into the directory (Bug 817295 http://hg.mozilla.org/comm-central/rev/d2a331abb0dc).
Comment 9 User image Mike Hommey [:glandium] 2016-01-05 00:09:44 PST
(In reply to Philip Chee from comment #7)
> We want the user*-example.css. Examples on the internet refer to these files.

You can add them to comm-central if you need them.

> > - Does it make sense to keep all the default profile related File Location
> > Provider keys? (there are multiple keys inheriting from
> > NS_APP_PROFILE_DEFAULTS_50_DIR)
> SeaMonkey does use that

Likewise, in fact, you can add the keys to a directory provider in seamonkey.
Comment 10 User image Philip Chee 2016-01-05 10:12:13 PST
>> We want the user*-example.css. Examples on the internet refer to these files.
> You can add them to comm-central if you need them.
Ah we seem to have a local copy of those files. Sorry about that.

>>> - Does it make sense to keep all the default profile related File Location
>>> Provider keys? (there are multiple keys inheriting from
>>> NS_APP_PROFILE_DEFAULTS_50_DIR)
>> SeaMonkey does use that
> 
> Likewise, in fact, you can add the keys to a directory provider in seamonkey.
Oooh. I can. Great! Are there any docs on that?
Comment 11 User image Mike Hommey [:glandium] 2016-01-05 13:04:08 PST
(In reply to Philip Chee from comment #10)
> > Likewise, in fact, you can add the keys to a directory provider in seamonkey.
> Oooh. I can. Great! Are there any docs on that?

You have one already, in nsSuiteDirectoryProvider::GetFile. Just add what you need to it.
Comment 14 User image Mike Kaply [:mkaply] 2016-05-03 14:10:52 PDT
This should have been in release notes.

This was a major source of preloading profiles in enterprise.

In particular default localstore.rdf, default userChrome/userContent.css and default bookmarks.

This is a big loss.
Comment 15 User image guillaume.boucher 2016-05-04 08:08:33 PDT
Hi all, I just want to make sure. If I understand the situation correctly it's not possible anymore to preload my profiles since Firefox 46. And there's no workaround!? Then what Mozilla propose to help us people who need to deploy Firefox in schools, enterprises, etc.? Not trying to be a troll here. I just need to get the job done. Thanks

Guillaume Boucher
Comment 16 User image cxlambert 2016-05-04 14:07:01 PDT
This was a widely used feature that corporate environments, schools, etc. used in order to preload profiles.  I am experiencing the same situation as Guillaume.  What do you propose we do now to accomplish the same thing?
Comment 17 User image Tommaso Vitale 2016-05-05 06:07:56 PDT
We use firefox in ours University Labs as "default browser" because is free, easy to update, secure and highly configurable. 
As Guillaume Boucher and Cxlambert I don't understand this change and also we need it. 
Now we are trying to find hard-workaround and also a browser alternative :-( and like Mike Kaply said "This should have been in release notes." that we read *before* any upgrade.
Comment 18 User image paulo.furches 2016-05-05 15:32:29 PDT
+1 on this.  We used this feature to set some simple default prefs like homepage but most importantly we used it to prepopulate zScalar and our Root CA.  This is a mandatory mod for us.  We are federally funded and we cannot deploy unfiltered browsers. Our filter is zScaler which requires us to have the Root CA imported when the profile is created.

Yes I am aware you can compile and programmatically import CAs but that is problematic because we have 24,000 devices and several operating systems.

On the bright side, this gives me a perfect reason to REMOVE Firefox from all 24,000 devices in our school system as it is now insecure and cannot be configured correctly any longer. :-P

Not covering this in release notes, well that is just insult to injury people.
Comment 19 User image Mike Hommey [:glandium] 2016-05-05 16:53:11 PDT
(In reply to Mike Kaply [:mkaply] from comment #14)
> This should have been in release notes.
> 
> This was a major source of preloading profiles in enterprise.
> 
> In particular default localstore.rdf, default userChrome/userContent.css and
> default bookmarks.
> 
> This is a big loss.

FWIW, default bookmarks haven't been taken from the default profile since well before this change.

Also, do you all realize that the default profile is only used when running Firefox for the first time, and that if you needed to update things in the default profile, it wouldn't update user profiles?
Comment 20 User image paulo.furches 2016-05-05 16:58:03 PDT
(In reply to Mike Hommey [:glandium] from comment #19)
> (In reply to Mike Kaply [:mkaply] from comment #14)
> > This should have been in release notes.
> > 
> > This was a major source of preloading profiles in enterprise.
> > 
> > In particular default localstore.rdf, default userChrome/userContent.css and
> > default bookmarks.
> > 
> > This is a big loss.
> 
> FWIW, default bookmarks haven't been taken from the default profile since
> well before this change.
> 
> Also, do you all realize that the default profile is only used when running
> Firefox for the first time, and that if you needed to update things in the
> default profile, it wouldn't update user profiles?

Well aware of that.  But the fact is that YOU COULD update initial user settings such as root ca when Firefox first launched.  If you use zScaler for filtering this is a requirement. No zScaler Root CA, then all web pages come back untrusted. You could also use this to populate lots of settings in the prefs.js file as well.
Comment 21 User image Hector Zhao [:hectorz] 2016-05-05 17:55:33 PDT
For bookmarks and prefs, distribution.ini[1] could be helpful; certs will require an extension, I think.

[1]: https://wiki.mozilla.org/Distribution_INI_File

(In reply to Mike Hommey [:glandium] from comment #19)
> 
> FWIW, default bookmarks haven't been taken from the default profile since
> well before this change.

Placing a bookmarks.html into default profile and it would take precedence, although not reliably so (bug 1207965).
Comment 22 User image Mike Kaply [:mkaply] 2016-05-06 06:38:15 PDT
As has been noted, it's a lot more than certs.

Why was this function removed? The referenced bug give no reason for the removal. Did it fix or improve something?
Comment 23 User image Mike Kaply [:mkaply] 2016-05-09 08:22:39 PDT
I could I please get an answer to the above query?

This is already causing breakage for enterprise (outside of the ESR), and I'd like to investigate getting it reverted.
Comment 24 User image cxlambert 2016-05-10 09:10:24 PDT
Are developers reading these posts still?  I just want to make sure our concerns aren't going unnoticed.
Comment 25 User image Liz Henry (:lizzard) (needinfo? me) 2016-05-10 09:55:42 PDT
It looks like this is meant to prevent malware problems or other abuse, see https://bugzilla.mozilla.org/show_bug.cgi?id=1269706#c8
Comment 26 User image Liz Henry (:lizzard) (needinfo? me) 2016-05-10 10:36:49 PDT
I asked about this in a meeting today and 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/.
Comment 27 User image Benjamin Smedberg [:bsmedberg] 2016-05-12 06:54:51 PDT
This feature was being abused and was (partly) removed as part of continuing anti-malware.

To the extent that we want to support enterprise customization, that should all be taken care of explicitly through the distribution/ mechanism. That system already supports adding default bookmarks (though not replacing the defaults entirely) as well as certain other customizations. If you would like additional features as part of the distribution/ set, please file a bug in Firefox:General and cc me and Kev Needham.
Comment 28 User image Ray Satiro 2017-01-31 15:20:05 PST
I have read through this thread but don't understand what I should do. We have several computers on 45ESR right now and rely on browser/defaults/profile for the following:

bookmarks.html
cert8.db
localstore.rdf
prefs.js
search-metadata.json
chrome/userChrome.css
chrome/userContent.css

I would like to be prepared for the next ESR and I recently noticed in later versions of Firefox this no longer works. For example Trunk and Aurora I was doing some testing recently and I tried to shut off app auto updates and I couldn't shut them off via a default prefs.js.

We're not going to spend several hundred on CCK. I understand you think removing this option may help prevent against malware that plants files there but couldn't malware just do something else if it can plant files there? Like if you were malware and someone stopped you from adding prefs there wouldn't you just find some other way like inject in omni or something? It seems like you're making this harder unnecessarily.
Comment 29 User image Mike Kaply [:mkaply] 2017-01-31 15:22:48 PST
1. The CCK2 is free. You only pay if you want support.

2. I provided a workaround here:

https://mike.kaply.com/2016/05/24/default-profile-directory-doesnt-work-in-firefox-46/
Comment 30 User image Ray Satiro 2017-01-31 15:28:35 PST
Also to amend to what I just posted I was told some profiles have custom extensions and extension data is included like browser/defaults/profile/adblockplus/elemhide.css etc, and some use local-settings. So apparently more is involved that I don't know of.

(In reply to Mike Kaply [:mkaply] from comment #29)
> 1. The CCK2 is free. You only pay if you want support.
> 
> 2. I provided a workaround here:
> 
> https://mike.kaply.com/2016/05/24/default-profile-directory-doesnt-work-in-
> firefox-46/

Thank you for all your hard work Mike, I will be sure to look into that. Our critical issue is keeping certificates working, we have to use a web proxy for some of the computers to scan https traffic.

Note You need to log in before you can comment on or make changes to this bug.