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

VERIFIED FIXED in M15

Status

()

Core
Preferences: Backend
P3
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: Chris McAfee, Assigned: neeti)

Tracking

Trunk
Sun
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
I think all comments in prefs.js get overwritten,
this makes it awkward to hack on this file, all
your changes keep getting nuked.
(Assignee)

Comment 1

19 years ago
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?

Comment 2

19 years ago
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.
(Reporter)

Comment 3

19 years ago
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?
(Assignee)

Comment 4

19 years ago
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.

Comment 5

19 years ago
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.
(Assignee)

Comment 6

19 years ago
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?
(Assignee)

Updated

19 years ago
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
(Assignee)

Comment 7

19 years ago
Changing summary to Read user.js on startup after prefs.js is read. The user.js
file should not be overwritten.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 8

19 years ago
Checked in a fix

Updated

18 years ago
QA Contact: paulmac → sairuh

Comment 9

18 years ago
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!
(Assignee)

Comment 11

18 years ago
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

Comment 12

18 years ago
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 → ---
(Reporter)

Comment 13

18 years ago
Right, user.js should be read-only from the
mozilla app perspective.
(Assignee)

Updated

18 years ago
Target Milestone: M11 → M15

Comment 14

18 years ago
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
(Assignee)

Comment 15

18 years ago
Checked in a fix.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago18 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?
(Assignee)

Comment 18

18 years ago
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.