50038 - prefs in user.js get written to prefs.js

Status: VERIFIED INVALID

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

Description

[Akkana Peck]

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.

Comment 1

[sairuh (rarely reading bugmail)]

this should not happen.

Comment 2

[Daniel Veditz [:dveditz]]

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.

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[sairuh (rarely reading bugmail)]

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.

Comment 5

[Matthias Versen [:Matti]]

*** Bug 185380 has been marked as a duplicate of this bug. ***

Comment 6

[Jonathan Baron]

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: [e-mail]

Comment 7

[Jesse Ruderman]

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.

Comment 8

[Jonathan Baron]

Can anyone tell me where I got the idea that these changes were
supposed to go in user.js?

Comment 9

[Jonathan Baron]

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.

Comment 10

[Florian Effenberger]

*** Bug 257706 has been marked as a duplicate of this bug. ***

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 262014 has been marked as a duplicate of this bug. ***

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 171225 has been marked as a duplicate of this bug. ***

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 252307 has been marked as a duplicate of this bug. ***

Comment 14

[Adam Guthrie]

*** Bug 301696 has been marked as a duplicate of this bug. ***

Comment 15

[Adam Guthrie]

*** Bug 310586 has been marked as a duplicate of this bug. ***

Comment 16

[wkearney99]

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.

Comment 17

[Peter Weilbacher]

*** Bug 316306 has been marked as a duplicate of this bug. ***