Closed Bug 155080 (QLProfileLoss) Opened 22 years ago Closed 22 years ago

prefs / profile lost while mozilla left idle (quickstart / quicklaunch active)

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Product:
Core Graveyard
Component:
QuickLaunch (AKA turbo mode)
Platform:
x86
Windows ME
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: mjcarman, Assigned: law)

References

Details

(Keywords: dataloss, Whiteboard: [adt1 RTM] [ETA 08/07])

Attachments

(7 files, 1 obsolete file)

Proposed fix
5.11 KB, patch
morse
: review+
bryner
: superreview+
jud
: approval+
Details | Diff | Splinter Review
Additional patch that adds Mutex lock around DoProfileStartup on alternate code path
854 bytes, patch
morse
: review+
bryner
: superreview+
jud
: approval+
Details | Diff | Splinter Review
Patch that moves SavePrefFile call ahead of DoProfileShutdown
2.11 KB, patch
ccarlen
: review+
bryner
: superreview+
asa
: approval+
Details | Diff | Splinter Review
The final patch, no matter what, I swear
2.14 KB, patch
caillon
: review+
bugzilla
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Perl script that baks up moz prefs files
86.65 KB, text/plain
Details
Perl script that baks up moz prefs files
86.65 KB, text/plain
Details
Perl script that restores moz prefs files from back up
84.94 KB, text/plain
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611
BuildID:    2002061104

Running Moz 1.1a under WinME. Computer is often left running unattended.
(Mozilla generally not running, but quicklauch is active.) Sometimes this
results in all preferences being lost. When I attempt to start mail/news, the
"new account" dialog comes up. My prefs.js file has apparently been deleted and
replaced with a minimal default version. (File size down to < 2 KB from 24 KB.)
Shutting down all moz processes and restoring the file from backup fixes things,
although moz still thinks it's being run for the first time when restarted.

I'm also running v1.1a on a WinNT computer but have not seen the problem there,
so it may be dependant on OS interaction.

This may be related to bug 122114. The symptoms are the same, but the trigger is
not.

Reproducible: Sometimes
Steps to Reproduce:
This is harder. :( All I've done when the problem has occured is
1. Have 1.1a installed on WinME
2. Have quicklauch running, but no other mozilla components
3. Leave the computer alone for a few hours...

Actual Results:  Sometimes nothing, sometimes prefs are lost.

Expected Results:  It should not have deleted my preferences!
I just had the exact same problem running Mozilla 1.1a and also under Windows ME.
I lost all my preferences and accounts. Although, when I want into
c:\windows\profiles\ and went into Mozilla's application data directory, all the
data was still present.

This happened to me just after I closed mail and news and reopened it.
Quicklanch was active and it was only a matter of seconds between closing
Mozilla and reopening it.
This specific error (QL on, idle, losing prefs and accounts etc.) happened to me
twice since I installed Mozilla 1.1a. I did not experience this behaviour with
1.0RC2, so I propose adding the regression keyword. 

I think http://bugzilla.mozilla.org/show_bug.cgi?id=131906 is related, but that
bug  seems to be the more general case with the same symptoms. 
Just had this happen for the first time under WinNT, so it can happen there, 
it just seems to be rarer.
Confirming bug as new per various comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
->quickstart
Assignee: ben → law
Component: Preferences → QuickLaunch (AKA turbo mode)
QA Contact: sairuh → gbush
I ran into this on my Win 98 machine at home using Mozilla/5.0 (Windows; U;
Win98; en-US; rv:1.0.0) Gecko/20020621 Netscape/7.0. Very frustrating. My
prefs.js was set to a default and even the prefs.bak was trashed, probably
because I tried various things to retreive my prefs.js.  I *think* I was doing
the following when this happened: I was browsing without launching MailNews. I
tried to do a 'send page" and was prompted to create a new account! 
This has been happening lately to a lot of people (Paul Wyskoczka, Gregg
Landskov). I have Turbo on.
Keywords: dataloss, nsbeta1
*** Bug 157208 has been marked as a duplicate of this bug. ***
transferring ADT grafitti from Bug 157208.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 RTM] [ETA Needed]
Raising the priority of this.  At least 5 people have seen this recently.  We
need to investigate this.  Steve or Bill, can you look into this?  This appears
to be Quick Launch related.
Whiteboard: [adt2 RTM] [ETA Needed] → [adt1 RTM] [ETA Needed]
we've had sporadic reports of mail directory prefs getting corrupted, but never
found any way of reproducing the problem. 
I have set up 2 machines in lab with branch builds from 7/15 or 7/16- to leave
idle and hopefully reproduce. Is anyone seeing this on recent builds? Most noted
here are Moz 1.0 or NS from June.

See also bug 147822 

Paul and Gregg, when did you see this?  In the dup bug, Varada was using the 7/3
build.

Grace, my understanding of this bug is that the app is shut down but quick
launch is still running.
I have intermittantly seen this on my Win98 machine only. My Win2000 has not
ever exhibited this behavior.

It happened as recently as yesterday and as long as 1-2 months ago.  I spent
some time yesterday uninstalling all versions of mozilla and deleted my
mozregistry, mozver.dat files, and all other profile related folders, and
started over. 

In my case, I believe the computer was confused because I had .slt folders in
two different locations on the computer and it didn't know which one to point
to.  I got into this state because I had previously saved my profile folder to a
server (so I could keep a copy of my settings in case I lost them!!!).

After reinstalling a commercial daily, I pulled my profile down again from the
server, presumably in the right place this time.  I do not expect this problem
to resurface for me again, but will certainly be watching closely.
I have not experienced this bug.  I had a problem related to profiles.
This just happened to me this afternoon. I believe it requires only one profile
to have it happen (meaning no profile manager comes up when launching).  I had
used my profile and then exited (with QL on), and did not touch my system for at
least 60 minutes.  I came back from a lunch meeting and I believe, I could be
wrong, but I believe the app was launched and a browser window was up.  I
clicked on Mail and found the problem (it gave me the Account Wizard instead of
launching my existing mail accounts).  As a rule, I don't exit the app when I
leave for meetings or lunch during the day so that's why I haven't seen this
until I purposely exit the app and leave.  As a rule, I exit the app and shut
down my system before going home, so that's why I haven't seen this with my
routine behavior.  
I will set up a test account and try this again.  BTY, my prefs.bak will not
help me since it's the same size as the new prefs.js file.

My system is a winxp with 7-15branch build.  Trying to recreate now: I just
created a new profile and added all my mail accounts back in, copied all my
local folders and pop folders to this profiile, copied my bookmark.html,
abook.mab and history.mab files into this new profile and then deleted the
useless profile so I have only 1 profile.  I have launched the app,turned on
quick launch and exited.  I will wait 60 minutes and check it to see if I can
reproduce the problem (oh and this time I have saved my prefs.js before trying
this). I'll update when I find out what happens. 
Have it reproduced on 2 lab machines WinME and Win95
setup includes:
single profile with mail setup and used
QL on
app exited (all windows closed)=QL still on
leave idle for 2- 3 hours 
--
setup for two additional tests
1. single profile - same as above 
picture of prefs.js 1. before exit, after exit, before sign on

2. multiple profile -  same as above 
picture of prefs.js 1. before exit, after exit, before sign on (for both profiles)
Esther/Grace - now that you can reproduce this, pls go back one month to a
branch build and see if you have the problem.  Then, narrow down to the build
where this problem started happening.  Perhaps that may help in the checkin
analysis of what the cause may be so we can get a fix.
This happened to me again on my Win 98 machine at home.  This time I had exited
out of Netscape. When I returned to my machine, the application had launced
itself. When I tried to use Mail, the account wizard prompted me for creating a
new account.
At this time we can't reproduce this with exact steps, but we can reproduce it
within a 24 hr period on various windows platforms.  All we've done so far is to
 narrow down some criteria for making it happen (Quick Launch=on and single
profile) and ruling out what criteria prevents it from happening (multiple
profiles and QL off). We're not at a point of narrowing down a specific build
but Gayatri's home system has build 6-21branch and I was using 7-15 branch at
work. I haven't been able to reproduce it on my winxp with a newly created
profile within the last 24 hrs, so it may also be profile creation date related.  
See bug 131906 which might be dup of this one. 
*** Bug 131002 has been marked as a duplicate of this bug. ***
*** Bug 138309 has been marked as a duplicate of this bug. ***
I'm using the build 2002071408 and Windows 98 SE and I just have discovered this
bug. I was using ChatZilla and Mail & News, closed them and some minutes after
that I opened again Mail & News and voila!... the profile info (prefs.js) was
gone, even in the backup (prefs.bak)! It's all like it was described in the
initial comment.
QuikLaunch is on and I have a single profile (the default one).
Bug 157922 looks to be related (and may offer a more reproducible scenario).
Per comment 20, it's not profile creation date (existing 6.x prolfiles) related
because Grace's test in comment 17 she created new profiles and saw the problem
on both.
Adding Brian Nesse to cc: list.

Can anybody (Brian, or Conrad) explain when/why we would create a fresh prefs.js
file?  Given that we can't reproduce this reliably, I'm thinking we may need to
just work backward from the code that is overwriting the prefs.js file.
I talked to Brian about this bug and he explained to me how the pref I/O code 
worked, more or less.  We theorized that what might be happening is some sort 
of conflict between the currently executing instance of Mozilla and the newly 
started one that QuickLaunch starts up when the last window closes.

In order to test this, I added some debugging code to nsPrefService.cpp to log 
the prefs file I/O, and, to insert 10 second delays between the opening of a 
prefs file and the writing of it, and between the writing and the closing.  
I'll attach a patch in a moment that does this.

The good news is that this patch enables me to reproduce the symptoms at will.  
In looking at the log output (here's a portion):
555:##### Opening pref file C:\Documents and Settings\bill\Application Data\Mozi
lla\Profiles\Bill\xupq8bxq.slt\prefs.js...
556:##### ...file size=0
557:##### ...input stream created...
558:##### ...openPrefFile rv=0x00000000
559:##### Using user pref file...
560:##### Opening pref file C:\Documents and Settings\bill\Application Data\Mozi
lla\Profiles\Bill\xupq8bxq.slt\user.js...
561:##### ...UseUserPrefFile rv=0x80520012
576:##### ...closing...
590:##### ...WritePrefFile rv=0x00000000

you can see that we're seeing a 0 byte prefs.js file, and that this read is 
occuring precisely while my delay code is blocking the writing of the prefs.js 
from the original process.  Because the code reads an empty prefs.js, it has no 
user prefs.  When the new instance writes out its prefs.js, it writes out 
exactly the prefs it has, which is none.

I have pretty good confidence that this is exactly what's going on in the live 
code.  It will only be a problem with a single profile, because otherwise, the 
reading of prefs.js is deferred till the user picks a profile on the profile 
manager window.  In such cases, the terminating process will have written them 
long before that point in time so there will be no conflict.

The problem is hard to reproduce because the timing has to be just right to 
cause the reading of prefs.js in the new process to overlap the writing of 
prefs.js in the other.  This timing would likely be affected by whether Mozilla 
was active or not (due to system paging characteristics).  So the symptoms seem 
to match this theory pretty well.

That said, now all I need is a solution to the problem.  Suggestions welcome.
Blocks: 143047
Whiteboard: [adt1 RTM] [ETA Needed] → [adt1 RTM] [ETA 07/22]
Target Milestone: --- → mozilla1.0.1
Bill's analysis makes perfect sense.  I'm convinced that this would explain the 
symptoms that have been observed.
Can we do something to the terminating process so that it writes out the prefs 
before launching the new process?
Note that this problem should also occur without using turbo at all.  Suppose 
the user closed the last browser window by accident and then immediately 
relaunches the browser.
re: comment 32

Yes, it could happen that way, but this seems so timing dependent that my guess 
is that it is very unlikely to occur in other circumstances.  Plus, there are 
other mutual exclusion mechanisms used that may make it even more unlikely 
(e.g., the "MessageWindow" that is closed 'early' during restart).

re: comment 31

We could write the prefs earlier, but I'm not sure we could suppress the 
writing that would also happen later during normal shutdown.  But I don't know 
if the prefs-writing code is clever enough to not re-write if the prefs haven't 
been modified since last being written.  Brian?

A related approach might be to "log off" the user profile earlier (before 
starting the new process).  But I don't know if that's possible.  Conrad?

The various approaches seem to fall into one of these categories:

a. mutual exclusion - add some sort of mutual exclusion code so that secondary 
processes don't read the prefs.js file while we're writing it.  That could 
probably be Win32 specific code inserted locally in nsPrefService.cpp.  Or, we 
could go back to the logic of holding the existing Mutex object for the 
duration of the restart/shutdown process (see discussion in one of the bugs for 
which the restart code was the fix for).

b. modifying the restart code to avoid the problem - as described above

c. something else; one idea is to simply not restart when there's a single 
profile.  Part of the rationale for the restart was to avoid problems with 
multiple profiles.  The only benefit for single-profile users is the side-
effect of freeing leaked memory/resources.  Maybe that benefit isn't worth it?

Another simplistic fix might be to add some sort of command-line switch to the 
restart that says "sleep for nnnn milliseconds before starting" or something 
along those lines.

I think the criteria should emphasize simplicity and non-riskiness.
re: comment 32
I'd honestly be surprised if this could be reproduced by quitting and
re-launching... that window of opportunity is so small, and the user would have
to be so fast on the relaunch...

re: comment 33
The prefs code doesn't currently have a concept of a persistent dirty state.
Although I believe this could be added fairly easily it will likely not help.
One of the things that is saved in a preference is the last page visited...
which is almost always dirty, and therefore will inevitably cause prefs.js to be
written on exit.

As prefs need to be loaded as early as possible on launch, we can't do much as
far as delaying the read is concerned. I see two options, one is trying to force
the write to occur earlier. We currently read in profile startup, and write at
app shutdown... we should probably write in profile shutdown for symmetry.
Unfortunately, these two things appear to happen almost simultaneously:
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#866

The other option would be to try and delay the initiation of the shutdown
process until after the save has happened... Or, perhaps, implementing both
options would be best.
Attached patch Proposed fix — — Splinter Review 
Here's a proposed fix.

It add mutual exclusion code to nsAppRunner.cpp at the points where it reads
and writes the pref file.

The mutex code is re-used from nsNativeAppSupportWin.cpp where it has already
been used to protect win32 startup/shutdown.  To make it avaialable to
nsAppRunner.cpp, I just separated the declaration and definition and moved the
former to nsNativeAppSupport.h.  All code (except in nsNativeAppSupportWin.cpp,
of course), is wrapped with #ifdef XP_WIN.

Some notes:
- This works (well, that matters, I suppose).  I've got a console log
demonstrating as much which I'll add to this bug description a bit later.
- There is little risk of the new code being broken, since the meat of it is
code that has already been used for years (the Win32 Mutex logic).
- The scope of the change seems as limited as possible.
- There's a failsafe mechanism built-in: the Lock calls timeout after 30
seconds so worst-case (somebody holds the mutex and never releases it), we
resume after a 30 second delay.  This timeout can probably be scaled down
considerably (I made it 30 seconds to fit with the 20 second delay I inserted
into the pref-writing code).  I'd think 10 seconds is more than adequate.
- The only limitation imposed is the fact that the mutex is of a bit larger
scope than it *could* be.  We hold the mutex for longer than is absolutely
necessary and the coarse-grained nature of the mutex ID (a single mutex name
for all Mozilla implementations, for all profile names) means that we're
potentially blocking code that doesn't need to be blocked (for instance, saving
prefs.js for one profile using Mozilla will block Netscape from reading prefs
for some other profile).

The scope of the mutex is imposed by the fact that I wanted to put the code
somewhere where it could get at the Mutex implementation I already had.  I
don't think the other issue is worthy of note, since it only has material
effect in very unlikely circumstances and has negligible (if any) negative
impact regardless.
Attachment #91896 - Attachment is obsolete: true
Here's the console log demonstrating the effectiveness of the code I inserted.

What you see here is:
a. CreateMutex+Lock for the second process starting up (this mutex name is 
different than the one I added, BTW)
b. CreateMutex+Lock for the first process prior to saving prefs (note mutex 
name).
c. WritePrefFile begins (note countdown), in terminating process
d. CreateMutex+Lock for the second process, trying to obtain it prior to 
initializing the profile. Note that the typical "...wait complete..." message 
is absent this time!
e. WritePrefFile logic completes, at which point it releases the pref file 
mutex.
f. ...wait complete... happens to complete the Lock() request issued by the 
second process back at point d.
g. Second process reads the prefs.js file (which is not 0 bytes, now).

CreateMutex error = 0x00000000
Waiting (30000 msec) for mutex: MozillaStartupMutex...
...wait complete, result = 0x00000000, GetLastError=0x00000000
DDE: uType  =XTYP_UNREGISTER
     uFmt   =0
     hconv  =00000000
     hsz1   =0000c000:[Mozilla]
     hsz2   =0001c008:[Mozilla(0X004C0208)]
     hdata  =00000000
     dwData1=00000000
     dwData2=00000000
DDE result=0 (0x00000000)
WARNING: requested removal of nonexistent window
, file 
c:\branch\mozilla\embedding\components\windowwatcher\src\nsWindowWatcher.cpp, 
line 855
WEBSHELL- = 2
Releasing mutex: MozillaStartupMutex
GetPrimaryFrameFor() called while FrameManager is being destroyed!
WEBSHELL- = 1
CreateMutex error = 0x00000000
Waiting (30000 msec) for mutex: MozillaPrefFileMutex...
...wait complete, result = 0x00000000, GetLastError=0x00000000
##### Writing pref file C:\Documents and Settings\bill\Application 
Data\Mozilla\Profiles\Bill\xupq8bxq.slt\prefs.js...
##### ...backup created...
##### ...output stream created...
10
CreateMutex error = 0x00000000
Waiting (30000 msec) for mutex: MozillaStartupMutex...
...wait complete, result = 0x00000000, GetLastError=0x00000000
Message window = 0x003001A2
DDE server started
Releasing mutex: MozillaStartupMutex
Type Manifest File: C:\branch\mozilla\dist\WIN32_D.OBJ\bin\components\xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
9
nNCL: registering deferred (0)
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\initpref.js...
##### ...file size=2762
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\xpinstall.js...
##### ...file size=225
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\security-prefs.js...
##### ...file size=1410
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\mdn.js...
##### ...file size=825
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\mailnews.js...
##### ...file size=22763
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\inspector.js...
##### ...file size=2085
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\editor.js...
##### ...file size=3673
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\config.js...
##### ...file size=2141
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\all.js...
##### ...file size=34585
##### ...input stream created...
8
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\debug-developer.js...
##### ...file size=1821
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Opening pref file 
C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\winpref.js...
##### ...file size=8463
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
CreateMutex error = 0x000000B7
Waiting (30000 msec) for mutex: MozillaPrefFileMutex...
7
6
5
4
3
2
1
##### ...closing...
10
9
8
7
6
5
4
3
2
1
##### ...WritePrefFile rv=0x00000000
Releasing mutex: MozillaPrefFileMutex
...wait complete, result = 0x00000000, GetLastError=0x000000B7
### nsCacheProfilePrefObserver::Observe [topic=xpcom-shutdown data=]
##### Using default pref file
##### Opening pref file C:\Documents and Settings\bill\Application 
Data\Mozilla\Profiles\Bill\xupq8bxq.slt\prefs.js...
##### ...file size=845
nsPluginHostImpl::Observe "xpcom-shutdown"
##### ...input stream created...
##### ...openPrefFile rv=0x00000000
##### Using user pref file...
##### Opening pref file C:\Documents and Settings\bill\Application 
Data\Mozilla\Profiles\Bill\xupq8bxq.slt\user.js...
##### ...UseUserPrefFile rv=0x80520012
Steve and/or Conrad, can you review this fix, please?

I'll need a sr= also (in case any are watching).  I'm on my way in to the 
office and should be there shortly.

BTW, I think this fix should be branch-only.  There is code on the trunk that 
provides some protection against re-using profiles and I'm not sure how this 
code co-exists with that.
Blocks: 1.1
Comment on attachment 91997 [details] [diff] [review]
Proposed fix

r=morse
Attachment #91997 - Flags: review+
Comment on attachment 91997 [details] [diff] [review]
Proposed fix

sr=bryner
Attachment #91997 - Flags: superreview+
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
drivers' approval. pls check this in to the 1.0 branch, then replace
"mozilla1.0.1+" with "fixed1.0.1". thanks!
Keywords: adt1.0.1+, approval, mozilla1.0.1
law: when do you believe you can land this?
I believe I can land this real soon now (in a few minutes).
Keywords: adt1.0.1+ → fixed1.0.1
When I checked this in, I said sr=jag.  It was, of course, sr=bryner.  Thanks, 
Brian.
Law, we'll need something for the trunk soon. We can release note this for
1.1beta but final (early next month) will need a fix. 
Perhaps this is a completely irrelevant point at this stage, but it seemed worth
mentioning.
# Redundant backup of preferences files has been implemented in 1.1 Alpha.
 - From 1.1a release notes
*** Bug 156878 has been marked as a duplicate of this bug. ***
Alias: QLProfileLoss
*** Bug 158845 has been marked as a duplicate of this bug. ***
Using the steps I used last week to reproduce this bug- and branch build for
7/22, I do not see the problems I did (bug 157922)
waiting for results of testing by folks who experienced this regularly before
marking verified
I need to re-open this bug in the branch so I am removing the fixed1.0.1
keyword. I am still experiencing the problem using the 7/22 branch build.  I
opened and closed Netscape about 3 times and my preferences disappeared. I think
this problem is easier to reproduce on my slow Win 98 machine at home rather
than on the faster machines at work.
Keywords: fixed1.0.1
from reporter of bug 158845
I´m trying it on 2002072308 and I didn´t lost all pref, but first I lost the
mail accounts passwords and after that I lost the master password (and I know I
didn´t change it)
ARGH!  I just ran into this bug again today as well.  I am running 20020723 on
Win98, Turbo Mode ON, Single Profile.

I did not lose my bookmarks (consistent with previous instances), but did lose
all my Mail settings, my AIM setup, my password manager info, my form info, etc.
Whiteboard: [adt1 RTM] [ETA 07/22] → [adt1 RTM] [ETA 07/26]
Gregg, Gayatri (and anybody else witnessing this bug):  Can you have a look at 
your Profiles directories and see if there's any evidence that we've created a 
brand new profile (and sub-directory with salted name)?  These would be located 
somewhere like c:\Documents and Settings\<username>\Application 
Data\Mozilla\Profiles".  If you go to that directory and enter something 
like "dir /s /b *.slt" the output would be of interest.

The theory is that this bug involves processes simultaneously writing/reading 
the registry.dat file (my previous attempt at fixing this only protected the 
reading/writing of prefs.js).  I'm trying to force that scenario to see if it 
produces the symptoms, but without success so far.
In my case a new profile was not created.  Also, in case it helps, my laptop is
a 500 - 600 MHZ machine with 128M RAM. 
There is only one *.slt folder on my machine, I believe it is the same name I
had before.  It still contains *some* of my originial files like bookmarks, and
it looks like my cache folder still has lots of files in it.  So I don't expect
that it created anything new.

My prefs.js file is really small as expected.
OK, thanks for the info.  I've programmatically caused the registry.dat I/O to 
overlap but it doesn't seem to produce any ill effects whatsoever.  So it 
doesn't look like that's the problem.

Nobody can come up with a theory as to how/why *multiple* files can get lost.  
We know single files are subject to problems (as demonstrated with prefs.js) 
but it would seem very unlikely that this could cause numerous files to all get 
wiped out at the same time.

Perhaps it's something in the profile code...anybody out there with any clues 
on what might be going on there?
I have a profile in our lab on a dial up win98 system that I can reproduce this
within 5 minutes.  I have simplified the steps but not narrowed them down yet.

I use the same profile after it has edited the prefs.js file by deleting the bad
prefs.js and copying the good prefs.js file back into the .slt directory. 

Then I:
1.)Launch app by right mouse click on desktop icon and selecting Open (I don't
think this specific way of opening it is necessary other than possible timing)
NOTE: I have a screen name entered in my buddy list, with no password saved nor
signon launch selected.  I did this so I can see when the problem happens
without opening mail.  
2.) While launching I watch to see if it shows my buddy name in the AIM section,
if no buddy name then the prefs.js file has been wiped out.
2.)File|Exit after I see the screen name indicating the prefs.js file is still OK.
3.)Repeat step 1-3 again, rather quickly and sometimes multiple times until the
app finally launches. 

Result: Eventually you will see that you AIM setup is no longer there (I can get
to this point with this system and profile within 5 minutes), this means your
mail accounts and other prefs have been erased and a new prefs.js file was created.

I'm working on this some more to see if any particular action causes this.  This
is all I can offer at this time.  I did not see multiple .slt directories or
profiles. I did take a snapshot of the directory structure right before and
after.  I can attach them to this bug after I make sure they don't contain
system information.





Esther, it doesn't look as if you're using QuickLaunch, then?
I talked to Esther and witnessed the phenomenom first-hand.  To answer my own
question (about QuickLaunch): Yes, she did have QuickLaunch on.  In addition to
the process QuickLaunch shutdown was launching, she was launching additional
processes.  

Coincidentally, Steve Morse and I detected a very narrow hole in the defenses
against simultaneous reading/writing of prefs.js that I implemented over the
weekend.  It happens that this hole would require use of an additional process
to send another request at a particular point in time.  This is because the
trigger for reading prefs.js can be hit from another location that is not
protected by the mutex code I inserted.

I am in the process of plugging that hole.  I will do an optimized build and
deliver it to Esther overnight for testing on the machine in question tomorrow
morning.

*If* that fixes the problem there, then the only remaining question is whether
the additional occurrences of the bug (since the landing of the previous fix for
this bug in Monday's build) *all* involved the same scenario: QL on, user double
clicks the program icon while QL is doing its restart.

Esther thought that Gayatri maybe had done that.  I'm not sure about Gregg.
Yes, that is my scenario: QL on, select Netscape, right click on mouse and
select Open while QL is doing its restart.
This is the patch for the code I modified.  A .zip file with this patch
included will be delivered (via email) shortly.  Keeping my fingers crossed...
Comment on attachment 92866 [details] [diff] [review]
Additional patch that adds Mutex lock around DoProfileStartup on alternate code path

r=morse
Attachment #92866 - Flags: review+
Reports from QA are that the build with the attached patch does fix the problem 
of the disappearing prefs.js (on the one machine where we could reliably 
reproduce the problem).

There are still some negative results however.  Double-clicking the program 
icon while QL is restarting results in browser windows opening that 
are 'broken' in various respects (distorted or missing content, drawing 
problems, etc.).

Those issues seem to be much less severe and given that the problems are only 
evident in relatively obscure cases, my assessment is that the remaining 
problems are not necessary to fix for Mozilla 1.0.x or NS7.  My proposal is 
that we go with this additional patch, on the branch only.  We can work towards 
fixing the general problem (two instances simultaneously running) properly on 
the Mozilla trunk (the issues are slightly different there due to the landing 
of the profile-locking code).

Any comments?
Comment on attachment 92866 [details] [diff] [review]
Additional patch that adds Mutex lock around DoProfileStartup on alternate code path

sr=bryner
Attachment #92866 - Flags: superreview+
Me too.

My mail accounts and preferences were all clobbered just a couple days ago
within minutes of installing 1.1 over my 1.0 milestone install.  Really sucked.

I'm on Win98 Second Edition 4.10.2222 A

I'd like to ask if creating additional profile(s) has been confirmed as a
successful means of circumventing this issue?
Tommy, in all of our cases here having more than 1 profile does circumvent the
problem. 
Here are the specific side issues I saw when testing Bill's patch on 7-26:
If I click on the N desktop icon several times starting before the N appears in
the task bar at the bottom of the page,  I will get several brower pages loaded,
when the app finally opens.  

    * The front most browser page is garbbled at first and takes about 20
seconds to finish displaying but it completly displays.
    * The second and third browser pages that opened in the back are missing the
sidebar content and stay that way until the user clicks View|Show/Hide/My
Sidebar. I tried the sidebar tab to show/hide but that didn't appear to do
anything (could be a bug not related to this).

If I click on the N desktop icon several times starting after the N appears in
the task bar at the bottom of the page,  I may get several brower pages loaded
when the app finally opens or I may get only 1 (must be a timing thing)

    * All the browser pages that launch are OK. 

The scenario Esther describes sounds like an edgecase, and is less severe then
losing your prefs, let's get this checked into the branch so we can pound on it.

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Drivers' approval. pls check this in asap, then chang "fixed1.0.1" to
"verified1.0.1".
Keywords: adt1.0.1
Whiteboard: [adt1 RTM] [ETA 07/26] → [adt1 RTM] [ETA 07/30]
Attachment #91997 - Flags: approval+
Attachment #92866 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
fixed, again
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0.1+ → fixed1.0.1
Resolution: --- → FIXED
*** Bug 160005 has been marked as a duplicate of this bug. ***
Why is this bug resolved? I don't see any indication that this was fixed on the
trunk. 
I took the 7-30 branch build, installed it over the build without the fix and I
can still see the last reported problem (hitting the N button on the desktop
rapidly before the N appears in the task bar).  I can lose my prefs.js file
almost every time I do this with the new build.  Did this fix get in. 
re: comment 71

I wanted to indicate that it's been fixed on the branch.  It isn't clear that 
this is even a problem on the trunk (where there is additional profile-locking 
code now).  We can re-open it (which might happen anyway since there's now the 
report that says it isn't fixed on the branch).

re: comment 72

Yes, this fix went in (on 7/29, so it is in the 7/30 build).  Crap.  I have no 
idea why it doesn't work now.
Bill, it appears to continue happening when you install the fixed build over the
buggy build.  When I installed the fixed build into a new directory, I can't
reproduce the prefs.js file being wiped out.  However, I think most people will
install over the top of an existing build.  
re: comment 73 (response to comment 71)
Unless I'm misreading the roadmap, this bug was opened against the trunk. Either
way, it's still present in 1.1beta (2002072104). I haven't tried a more recent
nightly because I've seen no indication of this being fixed there.
Further testing shows that this still happens on builds installed in a new
directory or over the top of an existing build.  Also, I tested more like a user
would by Exiting, waiting for the icon to appear in the task bar then double
clicking on the desktop icon (not hitting the button quickly and continuously).
and then double clicking again due to the app not launching the first time.  We
ran into the problem, so this is not fixed yet.  Bill is looking into this.
Reopening as QA is still able to reproduce this in their lab. :-(
Status: RESOLVED → REOPENED
Keywords: fixed1.0.1
Resolution: FIXED → ---
Whiteboard: [adt1 RTM] [ETA 07/30] → [adt1 RTM] [ETA 08/01]
FYI: I sent Esther a build last night that had another fix.  I tweaked the 
QuickLaunch restart logic so that it suppressed the shutdown and restart if the 
user had only one profile.

That avoids the simultaneous shutdown/restart scenario that seems to trigger 
the occurrence of this bug.

Esther reports that this seems to fix the problem on the machine where she had 
been able to reproduce it.  It also avoids the incidental problem of bogus 
Navigator windows opening if you clicked on the program icon while QL was 
shutting down and restarting.

I'm not sure exactly where we stand/stood with respect to *requiring* the 
restart in the single-profile case.  Does anybody know if eliminating the 
restart will have any negative consequences other than the accumulation of 
leaked memory over time?  Are there any password manager, security, etc. issues 
that could arise?
Bill, half of the bugs reported here (this bug plus the 5 duplicates) are
against the trunk. Based on that admittedly small sample it looks like this also
has a definite impact on trunk build users.
Whiteboard: [adt1 RTM] [ETA 08/01] → [adt1 RTM] [ETA 08/02]
*** Bug 160522 has been marked as a duplicate of this bug. ***
More FYI: We abandoned the strategy of not doing shutdown/restart in the single 
profile case.  There are/were too many bugs relating to properly releasing 
profile-related resources when the last window closed.  Those are all resolved 
by doing the shutdown/restart and we didn't want to have to deal with all those 
bugs until we could find no alternative.

So, after lengthy discussion with Conrad, we decided that the saving of the 
prefs.js should occur before we shutdown the profile.  That way, prefs.js is 
protected by the profile lock (that is in place on the trunk).

It also changes the performance characteristics (or so I theorize) so that this 
seems to fix the problem with lost prefs.js files on the branch, also.  Esther 
is testing that more thoroughly.

I will attach the patch that moves the saving of prefs.js in just a second...

P.S. This latest patch will definitely help on the trunk.  We'll need somebody 
to test whether it fixes the problem entirely (or as best as can be 
determined).  Can anybody reproduce this consistently with trunk builds?  I'll 
leave the bug open till we've resolved the issue across the board.
This one is OK for branch and trunk.
One more data point...

I just uninstalled a daily branch build from Tuesday and then installed today's
branch build - 20020801 - (Win98, single profile, Turbo on), and the same thing
happened, prefs.js mostly wiped out.
I finished testing the patch I receive from Bill (15508020020731.1430.zip) I
received last evening.  I tested it by consistanly clicking the desktop icon
before the tray icon appeared (impatiently).  I tested it by double-clicking the
desktop icon after the tray icon appeared, waiting several seconds between
double-clicks (patiently) until the app launched.  These tests were done for
Single profile and multiple profiles.  I could not break the prefs.js file.  I
also tested it by Exiting the app and leaving it alone for an hour then
launching again (this was one of the original scenarios).  This can be checked
in now.
varada@netscape.com, charleshixsn@earthlink.net, dellacasae@alma.it,
rbeldin@atl.hp.com, srayzen@netscape.net, t3xt3x@inwind.it and
mjcarman@mchsi.com, you all were experiencing this problem and a fix is about to
land on the Mozilla trunk. As soon as we have builds with that fix (the morning
after the fix lands) can you please get a build and test this to make sure it
works as expected? The more testing we can get on this the better for 1.1 and
1.0.1. Thanks. 
I have consistenly reproduced this on the trunk build on the same system in the
lab I have been using for branch builds.  I can help verify this when it gets
checked into the trunk.
Comment on attachment 93601 [details] [diff] [review]
Patch that moves SavePrefFile call ahead of DoProfileShutdown

sr=bryner, but please test that this won't cause the profile manager to appear
due to a locked profile.
Attachment #93601 - Flags: superreview+
Comment on attachment 93601 [details] [diff] [review]
Patch that moves SavePrefFile call ahead of DoProfileShutdown

r=ccarlen. Ensuring that the prefs are written within the scope of a profile
lock is a good thing. Looked for other users of profile data and didn't find
any. The lock has been around on branch & trunk since mozilla1.0.
Attachment #93601 - Flags: review+
Comment on attachment 93601 [details] [diff] [review]
Patch that moves SavePrefFile call ahead of DoProfileShutdown

a=asa (on behalf of drivers) for checkin to 1.1. 
Let's get this in as quickly as possible so we can get some testing before we
ship 1.1. Thanks , law, for the fix and thanks esther for the testing.
Attachment #93601 - Flags: approval+
OK, I'm going to check this in now on the branch.

I'm currently doing a trunk build to make sure that the timing differences 
don't have any negative impact there (wouldn't that be just our luck).  Once 
I've verified that it works OK there, then I'll check it in on the trunk.
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Drivers' approval. pls check this in asap, then change "mozilla1.0.1+" to
"fixed1.0.1". thanks!
Keywords: adt1.0.1 → adt1.0.1+, mozilla1.0.1
Priority: -- → P1
fix in on trunk and branch

Marking fixed, changing keyword
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: adt1.0.1+ → fixed1.0.1
Resolution: --- → FIXED
*** Bug 156015 has been marked as a duplicate of this bug. ***
gbush/esther: can you pls verify this as fixed on the 1.0 branch, and trunk,
then replace "fixed1.0.1" to "verified1.0.1"? thanks!
*** Bug 160522 has been marked as a duplicate of this bug. ***
I took the trunk build this morning and the ug appears to be fixed.  I spent an
hour trying to break the prefs.js file with a single profile scenario (the same
one I could break last night within 3 minutes).  Clicking rapidly on the desktop
icon and then being a little more patient.  One thing I did notice with the
trunk that did not happen with the branch is  the AIM setup is not read in
alternate launches when I run thru this test.  The reason I mention this is
because that was usually the sign that my prefs.js file had been edited when
running my scenario and I thought that was a pre-warining that this bug would
happen eventually.  That doesn't seem to be the case with the build with the
fix.  I still lose the AIM setup alternately, but the prefs.js file does not get
rewritten.  Grace will test that scenario and log a new bug in bugscape.
So the trunk appears to be OK now.

Now I will test the branch build. 
Testing the am 8-2 branch build, I still see the bug. Are you sure this went
into a branch build for 8-2 am.  I'm going back to the lab to make sure I didn't
take the wrong build.
The purported fix definitely went in on the branch (rev 1.345.2.11).

If I heard Conrad right, the profile locking code *is* in effect on the branch.
 If that's the case, then I cannot figure out how we're bumping into problems
involving contention over pref-related files.

I'm not sure exactly how the profile-locking is accomplished.  Is it possible
that there's something subtle about the way we're launching the restarted QL
process that causes this locking code to break down?  I'm thinking specifically
about the fact that this process appears to run as a child process of the
original process.  Perhaps that means that it inherits some file handles or
access privilege that bypasses the profile lock?
Priority: P1 → --
I have a Win 98 machine that I can reproduce this on now- using Esther's profile
set up.  I am seeing it on the branch build after about 6 or 7 launches.
Hmmm.  I wonder if the fact that we only see it on Win98 offers a clue.  Maybe 
there's something different about the profile-locking implementation on Win98?
We're pretty much at a complete loss on this one.  What I think I need to do 
next is revisit investigating exactly what is going on in the cases where it 
fails.  We can't come up with any plausible explanation as to how it could 
still be failing in the manner we first diagnosed.

To do that, I need to insert some logging code and perhaps also some code that 
alerts us if we run into particular situations (e.g., a zero-length prefs.js 
file).  That has to be done in an optimized branch build and then executed on a 
machine where we can reproduce the problem.  Then, we'll look at the output and 
assess what has occurred and figure out a way to prevent it.

I'm concentrating on the prefs.js I/O code initially.  I could use some help 
inserting appropriate logging code into the profile manager code as well.  I 
can have a test build ready to run Monday morning.

Hope that sounds like a plan, 'cause it's the best I can come up with at this 
point.
Just a few thoughts from someone who adds diagnostic code to isolate
intermittent problems.  It might be useful to step outside the program and see
if noticing when the opens/reads/writes/closes are being made to the prefs.js
and correlate them to specific diagnostic messages that Mozilla generates.   On
HP-UX, I use a tool called tusc or trace that will trace all system calls and
timestamp when they occur.   You can then match up raw system calls to code that
may be somewhat abstracted within the application.   It might catch some area of
the code that we don't think is executing.   I don't know if there anything like
this under Win98, but there might be something under NT, 2000, or XP.  Just a
thought.

Another thought is to provide some sort of crude workaround while root cause is
being find.   My thoughts are to checkpoint the existing prefs.js periodically
during the execution of the program.   While this might be done externally via
script (multiple platforms cause problems) it might be best to do this within
the program itself.   Perhaps every so often Mozilla would validate the cksum
and size of the on-disk prefs.js against what it started with and noticing a
'difference' might put us closer to where the problem is occurring.   It also
would provide a crude mechanism for the user to have a backup of the prefs.js.
I do this manually with a copy of prefs.js right now, only I only notice the
difference in prefs.js when I start up Mozilla and find all my customizations
have dissappeared. :-(

I'll be willing to test on a WinXP and WinNT platform. 


Reopening per Comment #99 From Grace Bush. Removing fixed1.0.1.
Status: RESOLVED → REOPENED
Keywords: fixed1.0.1
Resolution: FIXED → ---
Whiteboard: [adt1 RTM] [ETA 08/02] → [adt1 RTM] [ETA 08/08]
Grace, are you reproducing this on the trunk with win98? Any other OS?
I did not see this on trunk build (commercial) for 8/2 but did see in branch,
since then I have been testing on test builds
Asa,  I just spoke with Grace, we want to make sure we are clear on this.  Grace
did see this with a trunk build before the fix on 8-1.  We both could reproduce
it with my sceario on 2 different win 98 systems with both branch and trunk. 
After the 8-1 fix that went into the branch and trunk, neither of us could
reproduce it on those same systems for the trunk build.  However we still saw
the problem with the branch builds.  Bill is still looking at this.
OK, this patch fixes a problem whereby we could be fetching a pref value before
the profile is initialized.  This could happen if a request comes in from a
third process while the QuickLaunch shutdown/restart is in progress.

Since the pref being tested is set true in all.js and there is no UI to change
it, 'hardoding' it so that true is implicit doesn't cost anything.  The code
being protected hasn't caused any difficulties.

Rearrangement of the logic could leave the pref test in place, but I'd rather
not deal with more significant changes at this time due to the increased risk
of doing so.
Comment on attachment 94272 [details] [diff] [review]
The final patch, no matter what, I swear

Bill explained this to me and this seems like the correct fix.	r=caillon.
Attachment #94272 - Flags: review+
Comment on attachment 94272 [details] [diff] [review]
The final patch, no matter what, I swear

sr=blake
Attachment #94272 - Flags: superreview+
Comment on attachment 94272 [details] [diff] [review]
The final patch, no matter what, I swear

a=asa (on behalf of drivers) for checkin to 1.0 branch
Attachment #94272 - Flags: approval+
adt1.0.1+, per verbal approval from Jaime, which I've changed to fixed1.0.1

Fix landed, QA has tested this fix in a one-off build today, will verify with
tomorrow's build
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: fixed1.0.1
Resolution: --- → FIXED
grace/esther: pls verify this as fixed in tomorrow's branch build. thanks!
Keywords: mozilla1.0.1 → adt1.0.1+
*** Bug 161447 has been marked as a duplicate of this bug. ***
Bill, if you've hardcoded a pref from all.js as 'true', shouldn't that pref be
removed from all.js ?
No longer blocks: 1.1
re: comment 115

Yes, that was part of the patch.
I have been testing this for 20 minute stretches- I cannot break it- left it for
awhile to see if the 'unused' symptom would cause a problem. 

Looks good - 8/7 branch
reopening and removing fixed1.0.1  I can reproduce this on my system and I also
could reproduce it on Grace's system.  We informed Bill, he found the cause.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Keywords: fixed1.0.1
It turns out that that last remaining hole was in AIM code.  It was writing out
prefs.js at application shutdown, which is after the profile is unlocked (and
not protected with the mutex code I added to nsAppRunner.cpp).

That's going to require changes to the AIM code, which in turn requires a
Bugscape bug: 18921 (http://bugscape/show_bug.cgi?id=18921).  I think we should
close this one and transfer our (Netscape's) attention to the bugscape bug.

In retrospect, moving the writing of prefs.js within the profile lock fixes this
problem for Mozilla builds.  The bug is only present in Netscape distributions
(branch and trunk, although I'm not sure we've reproduced on the trunk).
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
gbush/esther: pls verify this as fixed on the 1.0 branch and trunk. 

As noted in Comment #119 From Bill Law, the one remaining issue will be dealt
with in Bugscape bug: 18921 (http://bugscape/show_bug.cgi?id=18921).
Keywords: fixed1.0.1
Whiteboard: [adt1 RTM] [ETA 08/08] → [adt1 RTM] [ETA 08/07]
OK, I'll retest this on branch without AIM activated in Side bar.  
As I understand, it's not necessary to Install the app without AIM to test this.
 Bill correct me if I'm wrong.   I will then test the trunk again with a latest
build just to be sure the fix that went into the trunk on 8-2.  
I tested the branch and trunk again.  Without the Sidebar open, both branch and
trunk are OK.  With Sidebar open, the Address Book and Shopping tab active I
could wipe out the prefs.js file with a slightly differenet scenario on the
trunk (I did not check the branch).  Bill believes this is the same problem with
AIM as noted in bugscape bug 18921 due to the Address book being active in
sidebar and possibly the interaction AIM has with mail and the Address book.  So
I retested with Sidebar closed and could not reproduce the problem.  I will
verify this as fixed. I will test this new scenario with the bugscape bug fix.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1
I saw the same sympton today on Solaris 8 Sparc (bug 162550). I thought
quicklaunch is
Windows only ? Or is there another problem hidden behind both bugs ? 

Did the final patch checked into 1.0.1 also reach 1.1 ?

*** Bug 162552 has been marked as a duplicate of this bug. ***
*** Bug 162541 has been marked as a duplicate of this bug. ***
"savemozprefs" is a Perl script runs on windows as well as other platforms so
long as Perl is installed.  It exists to back up mozilla profile directories
and preferences.  It is accompanied by another script called
"restoremozprefs.pl" which restores files which were previously backed up by
"savemozprefs.pl"
"savemozprefs" is a Perl script runs on windows as well as other platforms so
long as Perl is installed.  It exists to back up mozilla profile directories
and preferences.  It is accompanied by another script called
"restoremozprefs.pl" which restores files which were previously backed up by
"savemozprefs.pl"

I've uploaded this file to help those who test Mozilla builds with the problem
described in this bug (#155080).

-- 

  -Tommy Butler
   see if I'm online »http://ooopps.sourceforge.net/online

   Tommy Butler <tommy@atrixnet.com>
   phone: (817)-468-7716
   6711 Forest Park Dr
   Arlington, TX
	76001-8403

   Download my résumé in PDF, MS Word, HTML, text
   http://www.atrixnet.com/

   the open source ooOPps Code Library (programs, scripts, code, tutorials)
   http://ooopps.sourceforge.net/pub/
"restoremozprefs.pl" is a Perl script runs on windows as well as other
platforms so long as Perl is installed.  It exists to restore mozilla profile
directories and preferences from back up.  It is accompanied by another script
called "savemozprefs.pl" which performs back ups on files which can later be
restored by using this script, "restoremozprefs.pl"

I've uploaded this file to help those who test Mozilla builds with the problem
described in this bug (#155080).

-- 

  -Tommy Butler
   see if I'm online »http://ooopps.sourceforge.net/online

   Tommy Butler <tommy@atrixnet.com>
   phone: (817)-468-7716
   6711 Forest Park Dr
   Arlington, TX
	76001-8403

   Download my résumé in PDF, MS Word, HTML, text
   http://www.atrixnet.com/

   the open source ooOPps Code Library (programs, scripts, code, tutorials)
   http://ooopps.sourceforge.net/pub/
I've got exactly the same problem.
Mozilla 1.1b, Win98SE, using quicklaunch.

But I see you are working on it. I hope to get a fixed Mozilla soon, thanks.

I allready posted in bug 162290 but eventually I found this bug (since I
searched on "preferences" and this bug only has "prefs", I think a lot of
diplucates are made, because the summary doesn't have enough keywords?)
Bug 162290 isn't a duplicate, I think. But I first thought I had the same
problem, so I Commented there first.
It sounds like a few folks are seeing this on branches/trunk besides 1.0.1.  We
may need to open a new bug (for those branches such as 1.1) or reopen this bug. 
Although I would like to continue to help, I don't know how to create an
autoexec.bat file, and my operating system is ME, not 98.

What I've been doing to get around the problem is sending the drafts as messages
to myself.  Not very efficient, but all I've got to go with.
*** Bug 163421 has been marked as a duplicate of this bug. ***
Blocks: profile-corrupt
*** Bug 163700 has been marked as a duplicate of this bug. ***
Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020816

First crash of Mozilla since I've installed that build (I had 1.1a before I
think), and my prefs didn't disappear! A crash would almost always create the
problem for me, so I'm keeping my fingers crossed! Cheers!
*** Bug 166834 has been marked as a duplicate of this bug. ***
*** Bug 131906 has been marked as a duplicate of this bug. ***
*** Bug 168184 has been marked as a duplicate of this bug. ***
I still see this one on Mozilla 1.1 Sun Sparc.
Was this patch checked into that branch ? If yes, this patch does NOT 
solve the problem, and we have to reopen.
re comment 139 - that cannot be this bug, as Sun does not have the Quicklaunch.
if you can't find another bug that relates to your problem, you should open a
new one.
*** Bug 169360 has been marked as a duplicate of this bug. ***
*** Bug 158144 has been marked as a duplicate of this bug. ***
*** Bug 122114 has been marked as a duplicate of this bug. ***
very rare, but I just lost my prefs.... quicklaunch was active.

1.2a (20020910).

this should be reopened or a spin-off bug should be created.
Summary: prefs lost while mozilla left idle (quickstart active) → prefs / profile lost while mozilla left idle (quickstart / quicklaunch active)
Waheed, do you have PC-Cillen running? It's a virus checker that has been known
to cause this.
Someone asked about PC-Illin from TrendMicro.   I use this virus checker on my
Windows XP system, where I have seen the problem.  I have not seen the problem
on my Win98 system with PC-Illin nor on a Windows NT system - which has Norton. 
nope, no antivirus software installed.

I just lost my profile again! how strange.

I believe it might be happening when you convert your profile from a previous
version of moz to the new one (first time I did it). And constantly start the
mail client before the browser(!) (right-click tray icon - mail). I think the
previous version of moz I had was 1.1 (wasn't the patch checked-in?).

no definite way of reproduction though.

I won't post anymore comments until it happens again using 1.2b and with a fresh
profile.
The loss of prefs (mail account) occured on Windows XP Home with mozilla 1.1
final, polish version. It has happened twice in two days (after not happening
for a couple of weeks since moz. 1.1 was installed).
I think that in both cases mail window was opened before the browser. And of
course quick launch was active.

I think this bug should definitely be reopened.
Will folks that still experience this problem do the following:

do a search for *.vbs and check for any signs of a visual basic virus that might
be renaming the prefs.js file that would cause Netscape to lose the mail
preferences.

this was just in from support folks and it may be related here
I do not use quicklaunch. I do have a single profile (4 mail accounts + 1
newsgroup account). I leave browser and mail running on my WinXP Pro laptop,
typically hibernating at the end of the day rather than shutting down. I've had
3 variations of this problem. The first time I just lost mail preferences &
re-entered them. The second time the wizard came up telling me I had lost
preferences but I shut down Mozilla and re-started and preferences were there.
The third time I lost preferences and bookmarks and they wouldn't come back. I
had switched to Mail as my preferred first app. For now I am making my own copy
of prefs.js
I too do not believe this is associated with QuickLaunch. I am running Mac OS X,
and have had it happen to me with 1.2b and the latest nightly builds. As a
result, I am still using 1.1, which seems fine (apart from the odd reversion of
the bookmarks file to the default, but I can live with that).
this bug _was_ related to quicklaunch and _is_ now fixed.

if you've lost profile data when not using quicklaunch on the Windows build, or
with a more recent build than 1.1, then you are not seeing this particular bug.
there are a bunch of other bugs about profile data problems - take a look at the
other depencies of the tracking bug 123929 for possibilities.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: