I think all comments in prefs.js get overwritten, this makes it awkward to hack on this file, all your changes keep getting nuked.
I think we had this in 4.0, it was user.js or something like that. malmer used to know about it, it was a stealth feature which didn't get communicated very well. Yes, that would solve this problem. Maybe the code from 4.0 is still there?
So, essentially we would leave the behaviour of prefs.js as before(i.e. the comment get overwritten, this happens with 4.* also), but would like another .js file to be read in after prefs.js is read. Could this cause a security issue? Currently the prefs code does the following on startup. 1. Read initpref.js and all.js 2. Read any other .js files in the components directory. 3. Read the platform-specific files such as winpref.js, unixpref.js, and macprefs.js. Then, once the profile is selected, it reads in the correct prefs.js file. Only the prefs.js file gets overwritten. So, can we place the comment and other js processing in the files mentioned in 1, 2 and 3 steps.
At least right now, initpref.js and all.js are in the components directory. This is going to correspond to a systemwide directory which is not necessarily writable by the user, the same for every user on the system, and in any case those files will be full of other stuff which have nothing to do with the user's personalizations. Not the same thing at all as a per-profile user-editable .js file.
Would this user.js file contain user_pref(..) functions? There are bugs 8610, 8612 and 8613 which would like that the prefs file could be made not executable by a normal JS load? Will we run into the same case with a user.js file?
Changing summary to Read user.js on startup after prefs.js is read. The user.js file should not be overwritten.
Checked in a fix
sairuh, can you figure this out and verify? thanks
neeti, where is user.js located? cannot find it under defaults/prefs, components/ or the user's profile dir... has this perchance been made obsolete, or is moot from a QA perspective (i'm looking at opt bits, not debug bits)? thx!
The user.js file is located in the user's profile dir. It is not present there by default. A user could create this file, and put some of their preferences in this file. This file has the same format as the prefs.js file. Neeti
Right, user.js should be read-only from the mozilla app perspective.
Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.
Checked in a fix.
to test this, i did the following: 1. cp pref.js to user.js. 2. added/changed "browser.startup.homepage" to some other page in user.js. 3. restarted seamonkey. 4. verify that the homepage changed to what i set in step 2. neeti/akkana, one thing i noticed is that after step 4, the prefs.js was changed to reflect the change i made in user.js --is this expected behavior? am assuming yes. i did verify that if made a change to my Preferences during a session, they would only last for that session. once i quit/restarted seamonkey, i'd still get the prefs from user.js (which remains read-only, of course). tested w/opt comm bits: linux 2000.04.05.09 macOS 2000.04.05.10 winNT 2000.04.05.09
another thing i noticed is that profiles on winNT come with a user.js file --i had to create (copy) user.js from scratch on linux and macOS --expected behavior, or a bug?
Sarah, Did you start with a new profile on NT. If you did start with a new profile on NT you should not be seeing the user.js file. i.e. you would have to create it. If you started with an old profile, it is possible you could have the user.js file, because there was a bug last week where the user.js file was being created, which is now fixed. Also, the prefs.js is changed to reflect the change made in user.js --Yes, this is this expected behavior. Neeti
thx for the info, neeti! yes, i saw the user.js with an older profile --and with a new profile, it wasn't created. verifying this bug...