Closed Bug 12423 Opened 25 years ago Closed 24 years ago

Read user.js on startup after prefs.js is read.

Categories

(Core :: Preferences: Backend, defect, P3)

Product:
Core
Component:
Preferences: Backend
Platform:
Sun
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mcafee, Assigned: neeti)

Details

I think all comments in prefs.js get overwritten,
this makes it awkward to hack on this file, all
your changes keep getting nuked.
Chris,
I am not sure of how we could preserve the comments in the prefs.js. Currently,
when prefs are initialized, prefs calls JS_EvaluateScript(..) for the prefs
file, which ultimately calls the prefs callback pref_HashPref(..) to populates
the prefs hashtable. Next when we do a SavePrefFile(), the prefs are written out
to the prefs.js file from the prefs hashtable after they are sorted. Any
suggestions on how comments could be preserved within javascript?
I don't have a good idea for how to save prefs automatically, but how about
this?  Have another prefs file, like startup.js, which gets read on startup
right after prefs.js is read, but which is never overwritten.  Users can put
their own javascript (things with comments, things which they might want done
conditionally or which might involve more js processing, etc.) into that file
and be assured that it will be safe.
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?
Status: NEW → ASSIGNED
OS: Solaris → All
Summary: Comments in prefs.js should not get overwritten → Read user.js on startup after prefs.js is read.
Target Milestone: M11
Changing summary to Read user.js on startup after prefs.js is read. The user.js
file should not be overwritten.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Checked in a fix
QA Contact: paulmac → sairuh
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
Unfortunately, it turns out that if you create user.js, mozilla reads it, then
overwrites it.  I thought the whole point of user.js was to have a place where
the user could put javascript which would not get overwritten, so he could add
comments or logic or whatever.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Right, user.js should be read-only from the
mozilla app perspective.
Target Milestone: M11 → M15
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
Checked in a fix.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
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...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.