Closed Bug 50038 Opened 24 years ago Closed 24 years ago

prefs in user.js get written to prefs.js

Categories

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

Product:
Core
Component:
Preferences: Backend
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: akkzilla, Assigned: dveditz)

References

Details

(Keywords: regression) 

Add a pref to user.js, something fairly easily testable like
  user_pref("ui.textSelectBackground", "green");
Run mozilla, observe that the pref is in effect.  Exit mozilla.
Now edit user.js and remove the pref (or comment it out).
Run mozilla again, observe that the pref is still in effect.
You can't remove it by undoing what you did to add it, because it turns out that
mozilla has written another copy of the pref to prefs.js in the meantime.
You have to edit it out of both user.js and prefs.js to really get rid of it.
this should not happen.
Keywords: nsbeta3, regression
You sure this is a regression? I can't see anything that has changed in this 
area of the pref code. In fact I'd be willing to wager that Communicator 4.0 
worked exactly like this from the start. We have an internal sense of what pref 
values are "defaults", and any deviation from this is flushed into prefs.js 
regardless of where it got set.
Yes, this is exactly as Communicator behaved. Any value you set in user.js 
overrides prefs.js, but any deviation from the default gets re-written to 
prefs.js

You can, in fact, use default_pref() in user.js instead of user_pref(), and 
then that value will not be written back into prefs.js -- but at the cost that 
if the user ever changes the value in the product that change will be written 
to prefs.js, and I don't think the default_pref in user.js will then override a 
true user_pref.

Perhaps to get the effect you want you should set both default_pref *and* 
user_pref to the same values in user.js : then any change during the session 
would get written to prefs.js but would be ignored the next time you start up.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
mass verification of Invalid bugs: to find all bugspam pertaining to this,
set your search string to "MagaritaLuisaChascarilloAvoidsInvalidBugs".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. where relevant, do check that it's actually still a problem with ***recent
trunk builds*** on the all appropriate platform[s]

b. provide clear, compelling reasons why this bug should be considered a valid one.
Status: RESOLVED → VERIFIED
*** Bug 185380 has been marked as a duplicate of this bug. ***
Sorry for reporting a duplicate (15380) without finding this.  (I don't
know how I missed it.)

Based on comment #3, then perhaps the documentation at
http://www.mozilla.org/projects/security/components/ConfigPolicy.html
needs to have a comment about the problem of user_pref() and the
possibility of default_pref().
The author of that page is Jesse Ruderman.  I will send him a copy of
this when I get it: jruderman@hmc.edu

This is one of the reasons ConfigPolicy.html has instructions involving prefs.js
rather than user.js.  I'll keep this in mind if I ever give instructions
involving user.js.
Can anyone tell me where I got the idea that these changes were
supposed to go in user.js?

To answer my own question in #8,
http://www.mozilla.org/start/1.0/faq/general.html#1.5
is what let me to think I should use user.js and not prefs.js
I cannot find who maintains this, but it is the page that
should perhaps say something about the problem of undoing
changes to user.js if you don't like them.
*** Bug 257706 has been marked as a duplicate of this bug. ***
*** Bug 262014 has been marked as a duplicate of this bug. ***
*** Bug 171225 has been marked as a duplicate of this bug. ***
*** Bug 252307 has been marked as a duplicate of this bug. ***
*** Bug 301696 has been marked as a duplicate of this bug. ***
*** Bug 310586 has been marked as a duplicate of this bug. ***
The fact that SO MANY reports have come in on this issue seems to indicate
there's a PROBLEM.  The documentation needs to clarify what user.js actually
does.  As it's written one might get the impression it's for "user preferences".
 When, in fact, it appears to be an "override" file suitable only for
supplanting anything that might get set in prefs.js.  

FIX THE DOCS.
*** Bug 316306 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.