Closed Bug 113482 Opened 23 years ago Closed 23 years ago

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

Categories

(Core :: Preferences: Backend, defect)

Product:
Core
Component:
Preferences: Backend
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: aleksander.adamowski, Assigned: alecf)

References

Details

(Keywords: dataloss, smoketest)

Attachments

(2 files)

Navigator Languages preferences
8.24 KB, image/png
Details
Add languages dialog
2.79 KB, image/png
Details
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
laguage and font prefs horked is bug 108939
cc'ing alecf who has been changed the backend prefs engine yesterday.
ack! I will poke at this now, but in the mean time can someone see if the patch in bug 98736 fixes this?
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.
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...
Linux build 2001 120408 also looses prefs (Tabbed Browsing, specifically)
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.
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
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.
Win 32 build 2001120303 is ok for me. What about later nightly builds (me having a slower connection)?
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.
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.
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?
ok, walk84 on irc confirmed that my 7:44am checkin was causing the problem for him. backed myself out.
Assignee: bnesse → alecf
backed out. sorry I'll try to figure out what went wrong.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
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)).
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.
yes yes yes :) I just fixed this the right way in bug 112708
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. ***
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?
*** Bug 113481 has been marked as a duplicate of this bug. ***
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.
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)
Sorry? What do you mean? I erased my ~/.mozilla directory, so this surely can't be because of an "unfixed" prefs.js, can it?
I just double checked, there is *NO* "true" or "false" in my prefs.js, just true and false!
*** Bug 113782 has been marked as a duplicate of this bug. ***
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 → ---
Attached image Add languages dialog —
askwar: Have a look at these screenshots. Is this what you see?
Yes, that's exactly the situation I've got as well.
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
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. ***
*** Bug 113980 has been marked as a duplicate of this bug. ***
*** Bug 114020 has been marked as a duplicate of this bug. ***
Hmm. with trunk build 2001120516 it seems fixed. I can choose languages and default encodings without problems. Askwar? Do you confirm this is fixed?
Using build 2001120806 on Linux, I can confirm that the language stuff is fixed. Using build 2001120703 on Windows 2000, it is not fixed.
With 2001120808 on Windows 2000, it's also now working for me.
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.
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.
Okay, I just read Alec Flett's note about "true" vs. true, and I will go through and fix my prefs.js file.
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.
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.
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.
checkbox issue may have been fixed at 12/08/2001 15:48 mozilla/xpfe/global/resources/content/ bindings/checkbox.xml
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
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
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 → ---
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.
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).
Those problems are separate, reclosing this bug.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: