Loss of preferences, some of the lost preferences cannot be set to non-default values

VERIFIED FIXED

Status

()

--
critical
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: aleksander.adamowski, Assigned: alecf)

Tracking

({dataloss, smoketest})

Trunk
dataloss, smoketest
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
I'm using a trunk build 2001120408. After installing it I noticed that my
MailNews window now has the default layout (the one with a long folder pane).

After visiting Edit->Preferences, I came to discover that most (but not all) of
my settings were gone.

Things that are gone include navigator language settings and default encoding,
mouse wheel settings, tabbed browsing settings, mail related preferences (mail
window layout, addressing options etc), debug settings.

Things that _aren't_ gone include (but are not limited to) mail accounts, helper
applications, font and theme settings, mail character conding for reading and
composition.

What's worse, I can't configure some of those things - they aren't saved properly.
Default character coding for navigator is an example - I go to preferences
dialog, the coding is set to Arabic IBM-864. I change it to ISO-8859-2, click
OK, then go back to preferences dialog just to discover that coding is back at
Arabic.
this happened to me as well on osx, 12/4 build. i couldn't reset the "signature"
or the "use html" prefs. even when i went back to 6.2 i still couldn't set them!
i had to create a new mail server in order to get it to work again.

this is very very serious. cc'ing some mail people just in case this is
mail-related.
Severity: critical → blocker
Keywords: dataloss, smoketest
OS: Linux → All
Hardware: PC → All

Comment 2

17 years ago
laguage and font prefs horked is bug 108939

Comment 3

17 years ago
cc'ing alecf who has been changed the backend prefs engine yesterday.
(Assignee)

Comment 4

17 years ago
ack! I will poke at this now, but in the mean time can someone see if the patch
in bug 98736 fixes this?

Comment 5

17 years ago
I have the problems on todays windows release build. So this isn't mac specific.
Although I guess someone already changed this to all platforms.

Comment 6

17 years ago
I'm seeing 3 prefs at the top of my prefs.js file:
user_pref(".aim.session.autologin", false);
user_pref(".aim.session.password", "0");
user_pref(".aim.session.storepassword", false);

they also appear correctly farther down...
user_pref("NesseBr.aim.session.autologin", true);

I wonder if this is what's wrong...

Comment 7

17 years ago
Linux build 2001 120408 also looses prefs (Tabbed Browsing, specifically)
(Assignee)

Comment 8

17 years ago
is anyone seeing this on windows? I'm trying to figure out if this is an
uninitialized memory issue

Also, can people identify the exact build they are on? I checked in some pref
code at 7:30am PDT, and I don't know if that was it or not.

I'm still waiting on my builds, so any help is appreciated.
(Assignee)

Comment 9

17 years ago
also, backing out my 7:30 checkin would be another test:
cvs update -j3.17 -j3.16 mozilla/modules/libpref/src/prefapi.h
cvs update -j3.108 -j3.107 mozilla/modules/libpref/src/prefapi.cpp

Comment 10

17 years ago
I'm using a 2001120405 (hey, does that number reflect local timezone? it seems
to... in my case, EST) build on Linux, and I'm not seeing any prefs lost. I
admit I don't use mail at all, but I had been using tabbed browsing, and that
all seems okay.
(Reporter)

Comment 11

17 years ago
Win 32 build 2001120303 is ok for me. What about later nightly builds (me having
a slower connection)?

Comment 12

17 years ago
I just reproduced on Windows. You have to launch and quit once before you will
see it. Guessing it has something do to the data being written out to the prefs
file on previous quit.

Comment 13

17 years ago
I updated after the tree closed this morning, and I'm getting pref errors when
replying to a message:

abort() line 44 + 7 bytes
PR_Assert(const char * 0x032a37d8, const char * 0x032a37a0, int 0x00000e47) line 497
DIR_SetIntPref(const char * 0x0012e334, const char * 0x032a3954, char *
0x06953f20, int 0x00000000, int 0xffffffff) line 3655 + 29 bytes
dir_SaveReplicationInfo(const char * 0x06f061f8, char * 0x0012e334, DIR_Server *
0x06f06110) line 3895 + 33 bytes
DIR_SavePrefsForOneServer(DIR_Server * 0x06f06110) line 3991 + 23 bytes
DIR_GetPrefsForOneServer(DIR_Server * 0x06f06110, int 0x00000000, int
0x00000000) line 3183 + 9 bytes
dir_GetPrefsFrom45Branch(nsVoidArray * * 0x0012e680, nsVoidArray * * 0x00000000)
line 3278 + 13 bytes
DIR_GetServerPreferences(nsVoidArray * * 0x032ae344 class nsVoidArray * 
dir_ServerList) line 3348 + 22 bytes
DIR_GetDirServers() line 360 + 10 bytes
DIR_GetDirectories() line 346

Since DIR_ code is using PR_ASSERT, I can't continue. But Getting an int pref
was failing.
(Reporter)

Comment 14

17 years ago
Matthew: this bug doesn't hurt tabbed browsing, only preferences. If you didn't
change your tabbed browsing preferences from the defaults (like opening tabs in
the background), you won't notice anything. 
Do you say you do not see a loss of your custom settings pertaining to tabbed
browsing?
(Assignee)

Comment 15

17 years ago
ok, walk84 on irc confirmed that my 7:44am checkin was causing the problem for
him. backed myself out.
Assignee: bnesse → alecf
(Assignee)

Comment 16

17 years ago
backed out. sorry I'll try to figure out what went wrong.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 17

17 years ago
Aleksander -- right, no loss of preferences. (I had changed them from the
default, and they stayed that way.) Which fits with Alec's comment, since my
build is before that.

Comment 18

17 years ago
So I noticed that after running today's commercial build with the profile setup
for my IMAP account, at least 2 boolean prefs were stored as strings, i.e.,
user_pref("foo.bar", "true");  which should have been
user_pref("foo.bar", true);

Changing these back to booleans fixed the affected areas
(("mail.identity.id1.compose_html", false) and
("mail.server.server1.login_at_startup", true)).

Comment 19

17 years ago
I see that too.  Every pref value is being quoted, even when they aren't
strings. (booleans, numeric values)
That's probably why they aren't being read correctly: It's saving them as strings.
(Assignee)

Comment 20

17 years ago
yes yes yes :) I just fixed this the right way in bug 112708

Comment 21

17 years ago
After reverting, the prefs that are lost still can't be changed back.  It
preserves the string values in the prefs, and even if you change those prefs in
an earlier build, it isn't saved.

Note that you can go to about:config and look at all the prefs.  You will see
values that are quoted in prefs.js listed as type "string" when they should be
ints or booleans.

Find and replace in Notepad can help you get most of the strings out.
*** Bug 113509 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 23

17 years ago
I now have linux build 2001120508. I reverted to my previous prefs.js from the
day before Alec's checkin (luckily I have a script that regularly backs up my
profile).
Most of the problems are gone, but I still cant change the default character
coding for navigator from Arabic to something else. I also can't set preferred
languages for navigator - the list of languages is empty. Anyone else seeing
this? If so, is there a bug for this already?

Comment 24

17 years ago
*** Bug 113481 has been marked as a duplicate of this bug. ***

Comment 25

17 years ago
Me too!  On 2001120508 and 09 on Linux and 04 on Windows 2000, I cannot set the
default char set to something else.  Also the language selection is always empty.
(Assignee)

Comment 26

17 years ago
yes yes yes, this is a known problem. you have to hand-edit your prefs.js...stop
reporting "me too" until you've fixed your prefs.js.

you have to change all prefs with the value "true" or "false" to true or false,
and all numbers in quotes (i.e. "0") must be changed to be unquoted numbers -
i.e. 0)

Comment 27

17 years ago
Sorry?  What do you mean?  I erased my ~/.mozilla directory, so this surely
can't be because of an "unfixed" prefs.js, can it?

Comment 28

17 years ago
I just double checked, there is *NO* "true" or "false" in my prefs.js, just true
and false!

Comment 29

17 years ago
*** Bug 113782 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 30

17 years ago
Alecf: I've reverted to prefs.js from sunday (which must be OK), took the latest
build and I can't choose default encoding for Navigator, and I can't set
languages preference order.
The list of languages is empty, after entering two-letter language code and
clicking OK there's no action - the "Add Languages" window doesn't even close. I
have to click Cancel.
I'll attach screenshots. Reopening bug as Navigator languages settings cannot be
set.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 31

17 years ago
Created attachment 60622 [details]
Navigator Languages preferences
(Reporter)

Comment 32

17 years ago
Created attachment 60623 [details]
Add languages dialog
(Reporter)

Comment 33

17 years ago
askwar: Have a look at these screenshots. Is this what you see?

Comment 34

17 years ago
Yes, that's exactly the situation I've got as well.
(Assignee)

Comment 35

17 years ago
is this affecting anything else except your language settings? it sounds like
bug 108939, which has already been mentioned in this bug report...
Severity: blocker → critical
(Reporter)

Comment 36

17 years ago
Alecf: Yes, it seems to me that this is related to bug 108939, but that's not
for sure. Let's not mark this one as a dup and wait until 108939 gets fixed and
then we'll see. 
*** Bug 113843 has been marked as a duplicate of this bug. ***

Comment 38

17 years ago
*** Bug 113980 has been marked as a duplicate of this bug. ***

Comment 39

17 years ago
*** Bug 114020 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 40

17 years ago
Hmm. with trunk build 2001120516 it seems fixed. I can choose languages and
default encodings without problems.
Askwar? Do you confirm this is fixed?

Comment 41

17 years ago
Using build 2001120806 on Linux, I can confirm that the language stuff is fixed.

Using build 2001120703 on Windows 2000, it is not fixed.

Comment 42

17 years ago
With 2001120808 on Windows 2000, it's also now working for me.

Comment 43

17 years ago
Hmm, well, doesn't seem like anything is fixed.  I'm right now using 2001120808
on W2k, and none of the Edit->Preferences->Mail & Newsgroups settings seem to work.

While I'm inside the settings dialog, I can *enable* all of the settings,
however disabling does *not* work.  Further, if I leave the prefs dialog, the
settings return to the default settings.  In prefs.js, the changed settings
aren't stored.  Uhm, yes, some are stored.  For example, changing the number of
collecteed adresses is stored in the prefs.js file, however none of the
checkboxes is stored.

Comment 44

17 years ago
I'm seeing this problem on the Linux 2001120806 build.  I tried to go in to the
preferences gui and turn off the form data save option, and wound up clicking on
the checkbox several times to try and turn it off, before closing and reopening
the dialog.  The form data save option was turned off, all right, but so was my
Java and Javascript options, which I did not click on.  I tried to turn them on,
but it didn't seem to take, and I wound up manually editing my prefs.js file.

Comment 45

17 years ago
Okay, I just read Alec Flett's note about "true" vs. true, and I will go through
and fix my prefs.js file.

Comment 46

17 years ago
Okay, I went through and changed all "true" to true, all "false" to false, and
all quoted numbers to unquoted.  Now my problem is that the toolbars prefs for
the bookmarks button, the home button, the print button, all are off and i can't
seem to turn them on.  I edit the prefs.js file to turn them on, and then run
mozilla, and they are not there.  I quit mozilla and look at the prefs.js file,
and the appropriate toolbars prefs.js entries are simply gone.  If I run mozilla
and go to the preferences dialog and attempt to set them and then quit, the
entries are back, but they are left as false.

Again this is Linux 2001120806.

Comment 47

17 years ago
I get that too.  Win2k build 2001120808.

My temporary workaround is to show them again with the DOM Inspector.  It saves
correctly when I do that.

Comment 48

17 years ago
Problems with the checkboxes occur outside prefs as well.  Take a look at the
checkboxes in the find dialog.  You can toggle them on, but then they won't go
back off again.

Comment 49

17 years ago
checkbox issue may have been fixed at 12/08/2001 15:48
mozilla/xpfe/global/resources/content/ bindings/checkbox.xml
(Assignee)

Comment 50

17 years ago
and still nobody is reporting this as a general problem.

The toolbar buttons thing is because you have a disconnect between the UI and
the prefs. You need to go toggle the checkbox, hit ok, open prefs, toggle the
checkbox again, and hit ok. At that point, the toolbar buttons should start
matching your prefs.

I want someone to give me a reproducable test case, with 9 different prefs - 3
of each type (int, string, bool) each on 3 different panels.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 51

17 years ago
As of 12-09 the checkboxes work again, but when I hit the "Send"
button after composing an email message--no errors, just...nothing
happens!

linux.sea version
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 52

17 years ago
Using build 2001120906 on Linux.

Behaviour is now even more broken.  I've removed my ~/.mozilla directory and
installed the new build.  Right after this (at the first run) I went to the
prefs and toggled the "Go" button (under Navigator).  In the defaults, it was
turned off but I wanted it on.  So I clicked on the checkbox and closed the prefs.

When I reopened the prefs, the "Go" button was turned off again; but what's
worse, the value for "Home Page" "Location" is now "[object Window]".  With a
clean prefs, it's http://www.mozilla.org/start (or somesuch).

Hmm.  Strange.  If I check the "Go" button, go to "Appearance"->"Fonts", go back
to "Navigator", I cannot click on the "Okay" button.  Instead, I've got to click
on cancel, else the prefs won't close.   But, although the prefs do not close
when I click on Okay, they seem to be saved.

I checked the "Go" button, went to "Fonts", went back to "Navigator", clicked on
"Okay", clicked on "Cancel", opened prefs again, "Go" button is unchecked.  I
then went to "Fonts" and right away back to "Navigator".  "Go" button is checked.

Checking now the "Fonts" settings.  At first, "Western" was selected.  I changed
some font, closed the prefs, reopened and went to the Fonts section again.  No
encoding was selected, however the font change is present if I select Western
encoding.

Checking "Languages" settings.  At first, "English/United-States [en-us]" was
present in the lang order prefs, and "Western (iso-8859-1)" was selected as the
default encoding.  I added some language (Albanian [sq]) and clicked on ok. 
Opened prefs again, -> Lang settings, no default encoding was selected.  If I
chose something (eg. Arabic (IBM-864)), the setting won't be stored; or rather,
it will not be shown in the prefs dialog.  Ah, I suppose, that is, because in
prefs.js it's stored as:

user_pref("font.language.group", "[object Window]");

Okay, the "[object Window]" problem seems to occur in every prefs setting.  I
just changed "Max. number of pages listed" under "Composer" to 12 (was: 10). 
After ok, reopen prefs, it's now at 0.  Hmm, well, no.  In prefs.js it's stored
like so:

user_pref("editor.history.url_maximum", 0);

Unchecking "Maintain table layout" does not work.  It's always checked and I
suppose it's not stored in prefs.js, as the only 2 "editor.*" entries I've got are:

user_pref("editor.history.url_maximum", 0);
user_pref("editor.prettyprint", false);

"Mail & newsgroup" also doesn't store changes.

Well, sorry, I give up.  prefs seems to be totally bugged.

Comment 53

17 years ago
On Linux 2001120906, things are still awry.  Now my home page has been set to
[object window], and if I try changing it back by editing the appropriate text
field in the 'Navigator' prefs panel, it doesn't seem to take.

Just about all of my boolean options have become disabled through no action of
my own, and I can't seem to turn them on.  The checkboxes in the prefs panels do
work, but I have to press them twice to toggle.. I open prefs and they are not
set.  I click them once, they do not set.  I click them twice, and they visually
set, but if I exit prefs I see no change in the browser to reflect the change,
and if I go into prefs again, the checkbox is unset
see bug 114299 for the new problems (which are not the same as these old ones
and are reproducible in 2001-12-08 or newer builds with a new profile).

Comment 55

17 years ago
Those problems are separate, reclosing this bug.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
rs vrfy --was able to change several prefs to non-default values [2002.01.07.0x
bits].
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.