1234012 - Figure out what to do about the default profile

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Mike Hommey [:glandium]]

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

[Benjamin Smedberg]

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

[Mike Hommey [:glandium]]

(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

[Mike Hommey [:glandium]]

Attachment: Part 1 - Remove {localstore,mimeTypes}.rdf, user{Chrome,Content}-example.css

Comment 4

[Mike Hommey [:glandium]]

Attachment: Part 2 - Do not try to copy files from the non-existing default profile

Comment 5

[Mike Hommey [:glandium]]

Attachment: Part 3 - Remove the NS_APP_PROFILE_DEFAULTS_{NLOC_,}50_DIR directory keys

Comment 6

[Mike Hommey [:glandium]]

Attachment: 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

[Philip Chee]

(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

[Philip Chee]

(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

[Mike Hommey [:glandium]]

(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

[Philip Chee]

>> 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

[Mike Hommey [:glandium]]

(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 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b083f0748d81
https://hg.mozilla.org/integration/mozilla-inbound/rev/67f78903bbce
https://hg.mozilla.org/integration/mozilla-inbound/rev/ad491a4fcf8a
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b47cdfb4b12

Comment 13

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/b083f0748d81
https://hg.mozilla.org/mozilla-central/rev/67f78903bbce
https://hg.mozilla.org/mozilla-central/rev/ad491a4fcf8a
https://hg.mozilla.org/mozilla-central/rev/1b47cdfb4b12

Comment 14

[Mike Kaply [:mkaply]]

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

[guillaume.boucher]

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

[cxlambert]

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

[Tommaso Vitale]

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

[paulo.furches]

+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

[Mike Hommey [:glandium]]

(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

[paulo.furches]

(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

[Hector Zhao [:hectorz]]

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

[Mike Kaply [:mkaply]]

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

[Mike Kaply [:mkaply]]

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

[cxlambert]

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

Comment 25

[Liz Henry (:lizzard) (relman/hg->git project)]

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

[Liz Henry (:lizzard) (relman/hg->git project)]

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

[Benjamin Smedberg]

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

[Ray Satiro]

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

[Mike Kaply [:mkaply]]

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

[Ray Satiro]

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.

Comment 31

[Real Name]

Hi!

I face the same issue and i don't want to fiddle around with tools. 
So my Solution (expecting Windows) was to use the Operating Systems Default Profile function to deploy default settings for new users.
When a new User logs in, the Windows copies the Folder Structure of the "C:\users\Default" to the newly logged in user.


1) I copy the files and configs i need into following Folder:
"C:\users\Default\AppData\Roaming\Mozilla\Firefox\Profiles\test.default"

In this folder i copy is the cert8.db and the prefs.js (which only contains the settings i want to have per default)


2) Also there is a file "profiles.ini" needed to specify the default profile 
"C:\Users\Default\AppData\Roaming\Mozilla\Firefox"

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=1
Path=Profiles/test.default
Default=1


Hope that Helps somebody also stuck into the issue.