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: