41722 - prefs not sticking across sessions (user.js problem)

Status: RESOLVED WONTFIX

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

Description

[Phil Peterson]

Using 2000-06-04-20 commercial build on NT

1. Noticed that I was composing HTML for news.
2. Opened Account Manager and set compose mode to plain text. Also set special
folders to live on my IMAP server
3. OK'd the AM dialog
4. Brought up AM dialog again, all setting intact
5. Quit the app, brought up AM dialog, settings for HTML and special folders
have reverted to defaults.

Comment 1

[Phil Peterson]

Nominate for nsbeta2

Comment 2

[Alec Flett]

phil - we had a bug a week or so back where we were writing unitialized memory
to prefs.js during migration.. .then the next time you read in your prefs, it
would barf halfway through... from then on your profile would be broken. can you
try re-migrating?

Comment 3

[scottputterman]

marking M17

Comment 4

[Phil Peterson]

The profile I'm using was not created by migrating a 4.x profile -- it was
created from scratch a couple months ago.

Comment 5

[Phil Peterson]

Attachment: My prefs file

Comment 6

[Alec Flett]

hrm. I don't see anything unusual, in the prefs file, and my prefs are 
definately sticking... I'll go over the code and see if I can find what making 
this happen. libpref has this flag that it sets when there has been some error 
reading the prefs file.

I just thought of one other thing - phil, can you see if you have a user.js 
file? There was a bug that affected a few builds last month where a user.js 
file would be created, and then libpref would stop saving to prefs.js for some 
reason.. it rears its ugly head every so often, I'm wondering if this is it.

Comment 7

[Phil Peterson]

Bingo. Deleting user.js seems to fix it.

Comment 8

[lchiang]

Cool.  I will add this bit of info to my mail troubleshooting document on 
mozilla.org.

Comment 9

[leger]

Putting on [nsbeta2+] radar for beta2 fix.   Why are we creating user.js?  Can 
we not create this?

Comment 10

[Alec Flett]

since was fixed by removing user.js, I'm taking off the nbeta2 radar. There is
another bug about user.js somewhere, but I don't know where it is/who owns it.

Comment 11

[Alec Flett]

oh, and to answer Jan's question - no, we are not creating user.js - there was a 
bug a month or so ago where we would create one, and that would essentially 
taint your profile so all future builds would have this problem... but there 
were no milestone builds with this problem, so I argue that this is not a big 
deal since it only afects people who happened to use a nightly build when the 
old bug existed.

Comment 12

[Phil Peterson]

Good answer Alec

Comment 13

[scottputterman]

marking Wontfix because we don't plan on providing an upgrade to people who used 
this in between milestones.

Comment 14

[Alec Flett]

reopening and moving to Future. I'd like to fix this at some point so that 
user.js doesn't break the hell out of people who have it.

Comment 15

[Alec Flett]

changing to a preferences bug

Comment 16

[(not reading, please use [e-mail] instead)]

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

Comment 17

[Paul Chen]

nav triage team:

Really moving to future

Comment 18

[s.kumar]

I'm running the latest version (last night's build).

I searched on my hard disk and there is no user.js file and this problem still
persists.

Comment 19

[CoL]

Don't know if is a bug or not, but a real stupid thing. Prefs set in user.js
after mozilla start up, will go into the pref.js too. And when user want to
disable the lines in user.js (with delete, or hide (//)), recognize that nothing
new happend. So user have to edit the pref.js and get out these lines which was
in user.js. In this case, user.js has no sense.

Comment 20

[Alec Flett]

ok, there has been no traffic aside from this most recent comment... this bug is
about the old problem where a user.js got created even if you don't normally use
it, and it really hasn't plagued anyone else since the original problem was
fixed. Since this issue hasn't come back to haunt us in over 18 months, I'm not
going to try to track down what the real problem is.

my suggestion is to go file a new bug on the user.js problem, I'm going to
resolve this WONTFIX