103695 - prefs.js not preserved

Status: VERIFIED WORKSFORME

(Core :: Preferences: Backend, defect)

Description

[Calvin R. Smith]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913
BuildID:    20011091303

the prefs.js file is rewritten without my changes.
my change is the dom.disable_open_during_load



Reproducible: Always
Steps to Reproduce:
1. edit prefs.js
2. start mozilla
3. edit properties inside of mozilla
4. hand pasted preference is gone

Actual Results:  the line was removed

Expected Results:  the line should stay there

this makes the option useless since it doesn't stay

Comment 1

[Boris Zbarsky [:bzbarsky]]

Calvin R. Smith, the prefs.js file will get overwritten if it's edited while
mozilla is running.  Are you sure Mozilla is not running while you edit this
file? In particular, are you using QuickLaunch (-turbo option)?

Comment 2

[Chase Tingley]

As a side note, adding your custom preferences to 'user.js' instead of prefs.js
will avoid this kind of problem -- user.js isn't machine generated.

Comment 3

[Calvin R. Smith]

Using user.js seems to work.  let me test if for a while and see if it stays or 
not.
Since this is the ?recommended? file to edit then the instruction at:
http://www.mozilla.org/releases/mozilla0.9.4/#setprefs

should be modified as they lead one to change prefs.js

Comment 4

[Phil Bordelon]

Confirming that Mozilla steps on prefs.js, even when it's not running in the
background, on Win98/2001100803.  I was trying to add the same pref, and Moz
kept stepping on it, whether I had it loaded or not.  I agree on the
user.js/prefs.js bit--if prefs.js is unequivocally stepped on, we need to
evangelize use of user.js instead.

Comment 5

[Boris Zbarsky [:bzbarsky]]

You guys aren't using -turbo, right?

we should not be stepping on prefs.js.....  Please comment on -turbo use.

Comment 6

[Calvin R. Smith]

I just use the icon the installer generated.
I have, however, made sure mozilla.exe is not listed in the win2k task manager.

Comment 7

[Boris Zbarsky [:bzbarsky]]

And there is no mozilla icon in the system tray, correct?

Over to preferences:backend and setting status to NEW to investigate this
prefs.js-stomping.

Comment 8

[Brian Nesse (gone)]

What are you trying to set "dom.disable_open_during_load" to?

Comment 9

[Calvin R. Smith]

correct no icon in systray no mozilla.exe in taskmanager
the line i'm using in user.js is:
user_pref("dom.disable_open_during_load", true);

which works good in user.js but not in prefs.js

Comment 10

[Phil Bordelon]

I just wiped ~/.moz (or the Win equivalent) and prefs.js is no longer being
stepped on.

In fact, I'd be willing to be it's not being stepped on at all, Calvin . . . do
a search on the file for the xul_fastload bit and it may have been moved. 
Mozilla reorders all of the flags automagically, so it just might not be where
you think it is.

This, indeed, may have been my original problem--it was lost in a sea of other
bits, so I couldn't find it then.  Anyways, this WFM Win98/2001100803.

Comment 11

[Brian Nesse (gone)]

Yes, prefs.js is sorted alphabetically every time it's written out. Look for it
near the top of the file...

Comment 12

[Brian Nesse (gone)]

Closing as WFM based on Phil's comments.

Comment 13

[sairuh (rarely reading bugmail)]

mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

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

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)