589056 - Does not create "UChrm" folder(i.e. %profile%/chrome) automatically when I create a new profile.

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Alice0775 White]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100819 Minefield/4.0b5pre ID:20100819102200
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100819 Minefield/4.0b5pre ID:20100819102200

Minefield does not create "UChrm" folder(i.e. %profile%/chrome) automatically when I create a new profile.



Reproducible: Always

Steps to Reproduce:
1. Start Minefield with new profile
2. Exit Minefield
3. Look for %profile%/chrome

Actual Results:
 %profile%/chrome was not created

Expected Results:
 %profile%/chrome should be created. and *_example.css should be copied in the folder.

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/3900417b9594
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100818 Minefield/4.0b5pre ID:20100818215015
Fails:
http://hg.mozilla.org/mozilla-central/rev/9897ac78e6e3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100818 Minefield/4.0b5pre ID:20100818230222

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3900417b9594&tochange=9897ac78e6e3
Candidate:
Bug 556644 - Omnijar generation support for desktop builds

Comment 1

[Michael Wu [:mwu]]

This was intentional as bsmedberg and I don't like copying the defaults/profile files and no apparent regressions were seen from not seeding the profile directory with those files. Firefox now directly initializes places from the bookmarks.html in the omnijar. I wrote two patches to support this though - if we decide we want this, we can put it back.

Comment 2

[Benjamin Smedberg]

Indeed

Comment 3

[Alberto Grimaldi]

Hello, according to this page[1]:

''The administrator may alternatively put a user.js file in app_dir/defaults/profile/ ; this will put a copy of the user.js in all new profiles''

Now this behavior is disappeared.
I think this was very useful; any hope to have it back?

thanks

[1] http://www-archive.mozilla.org/catalog/end-user/customizing/briefprefs.html

Comment 4

[Benjamin Smedberg]

1) that really doesn't have much to do with this bug
2) no, administrators should be using default pref files, not user.js, to modify preference values

Comment 5

[Alberto Grimaldi]

(In reply to comment #4)
> 1) that really doesn't have much to do with this bug


ok, sorry.
I thought that the cause that defaults/profile/user.js is not copied to user_profile was related to mwu's statement:
>[...] don't like copying the defaults/profile files [...]



> 2) no, administrators should be using default pref files, not user.js, to
> modify preference values


ok, so I must edit prefs.js. 

thanks for your reply

Comment 6

[Iceberg]

I request the reopening of this bug.
Why?
Why, after a year, has not yet been resolved.

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

This has been resolved.  We have decided not to fix it because it was an intentional change.

Comment 8

[Iceberg]

Resolved is solution.
Resolved wontfix is not solution.
The problem is still unresolved.
This is a bug.
It was an intentional change?
Wrong change.

Comment 9

[Fabian Hernandez]

Hey there, I know this is old but we recently were requested to implement Firefox in our corporate environment for a specific application. The removal of this has been a headache from the beginning because we deal with many users per computer. If the Chrome folder has been removed on default account creation, how are we supposed to control the customization of the browser GUI for all users? What are the alternatives? 

Oh btw, that variable.profile folder is also a major pain in a corporate environment.

Comment 10

[Benjamin Smedberg]

Fabian, I don't understand. Why don't you just make the folder yourself?

Comment 11

[Fabian Hernandez]

Thanks for the reply. I would have a batch file make the folder and drop a css file for every windows profile but the variable.profile folder inside APPDATA where the chrome folder goes for all users is different every time for every user. So i have no way of making the folder in a directory that changes for every computer/user.

Any suggestions?

Comment 12

[Fabian Hernandez]

Initially i had a start up script run on each machine that was dropping the css file named userChrome inside the C:\Program Files (x86)\Mozilla Firefox\defaults\profile\chrome on install of firefox. This was supposed to populate all profiles. I tested it by running firefox.exe -p and deleting the profile created by default, and then relaunched and the settings were inherited after that for the single profile. So in a magical world this would be an awesome tool to have again :)

Comment 13

[Fabian Hernandez]

Just wanted update that i came up with a workaround for this. I decided to use the  -profile <y:\firefox profile> option in the firefox shortcut on all machines. I have placed a profile folder in an already mapped drive for users which includes the chrome folder and any other settings i want to control. Now all users are defaulted to that profile. I did have to remove the Modify rights of the prefs.js file so that no single user can change settings such as homepage and such and have it affect all users. I also hid the folder so it does not get accidentally deleted. Works great. Hope this helps someone looking for the same thing as me.

Comment 14

[Fabian Hernandez]

Second Update : Network Share wont work for many users as the Profile is locked on the first user that opens firefox giving an error on anyone else trying to use it. 

I made a log on script that drops a profile folder from a network location to %UserProfile% for every user on log on. And through GPO modified the shortcut on their desktop to point to that folder that was dropped and thats it! simple and clean.