28243 - linux: Profile not getting saved on Linux

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P3)

Description

[scalkins]

Saw this only on Linux commercial release build
Build 2000-02-17-08 M14

Steps to repro:
1) Remove the registry and profile folder to simulate a new install.
2) Launch Seamonkey and create a new profile. Start seamonkey as that new 
profile.
3) After the Browser appears, launch Instant Messenger via Tasks-->Instant 
Messenger. An Instant Messenger setup screen will appear. Select "I already 
have a screen name.." and click the 'Next' button.
4) Assign the Screen Name: "qanim05"  and the Password: "fifi" in the next 
dialog. Click on Next.
5)In the Aim Sign On Screen which appears next, go ahead and log in.
6) Now Select File-->Quit from the menu bar in either the IM standalone or the 
Browser. Note that Seamonkey does not exit cleanly, and you get the 
following in the session window - 
WEBSHELL- = 7
OnlineState: Validating
OnlineState: Transferring
OnlineState: Starting
OnlineState: Online
nsWebShellWindow::NS_DEACTIVATE
nsWebShellWindow::GOTFOCUS
AimAppOnWndUnload()
WEBSHELL- = 6
WEBSHELL- = 5
WEBSHELL- = 4
WEBSHELL- = 3
WEBSHELL- = 2
WEBSHELL- = 1
7) Force a close of the session window.                
8) Now relaunch seamonkey

Actual results: Notice you will be forced to add the Seamonkey profile back 
again. You'll also be forced to set up Instant Messenger again.

Notes: If you simply add a profile, then quit as soon as you've successfully 
logged in as that seamonkey profile, the profile is usually saved ok. Invoking 
IM setup seems to trigger this behavior when exiting seamonkey.

Comment 1

[scalkins]

Setting to confidential as I'm not sure what level of this we can make public 
knowledge.

Comment 2

[matt]

aim bug

Comment 3

[sairuh (rarely reading bugmail)]

reassigning qa to scalkins. :-)

Comment 4

[prass]

Notes:
I am using todays linux build 20000217 and see that whether I use IM or not, 
still see the profile not getting saved properly.

1. launch seamonkey
2. Create profile
3. Exit seamonkey
4. Relaunch
5. Observe that create profile comes up again.

So not sure if it is really an IM bug. Will try to find a dependency .

Comment 5

[scalkins]

Yes, I've noticed this is really inconsistent too. SOmetimes it would seem to 
keep the profile when exiting (without setting up AIM) but I could almost always 
see it happen when I went through Aim setup, therefore this testcase.

Comment 6

[Alex Musil]

From prassanna's comments, it looks like this is a general profile problem on 
Linux.  Reassigning to selmer and changing description.

Comment 7

[prass]

Not sure if these are the real dependencies:
http://bugzilla.mozilla.org/show_bug.cgi?id=27391
http://bugzilla.mozilla.org/show_bug.cgi?id=28256

Comment 8

[prass]

One more:
http://bugzilla.mozilla.org/show_bug.cgi?id=27342

Comment 9

[selmer (gone)]

I can't dup this on my NT box with 2000-02-17-08.  I followed the scenario and 
the second run just started up with my newly created profile.  I see the same 
behavior whether I kill the old mozilla.exe or not.

Bhuvan, is there anything special about Linux WRT the registry?  Is there a bug 
about them not closing the registry when we tell them to?

Comment 10

[Syd Logan]

wait, I'm looking at a bug about Linux version not exiting correctly (possibly
because it is stuck in a appshell loop). The question I have is, if we don't
exit, does the profile stuff get written out? If that is the case, the real bug
is we are stuck in the appshell loop. Notice how the bug says we have to
mannually kill mozilla.

Adding danm cause we've been talking about this issue. The bug I am referring to
is 27342.

Comment 11

[racham]

Killing the browser manually or crash in the browser would affect the saving of 
profile information. I guess we should trap the real problem that causes this 
abnormal quit. 

If the information is getting even without crash. that's definitely serious. 
Can someone who has the latest linux build try the following for me and see if 
this fixes the problem. 

in nsProfile.cpp add the following statement after line 866.

gProfileDataAccess->UpdateRegistry();

and see if the problem persists. thanks.

Comment 12

[racham]

As per the testing I have done, I couldn't reproduce this.

Comment 13

[racham]

I see this with latest comercial build. Registry flushing problems due to 
improper hang at the end. Anyway, I have a fix (in mind) to make this situation 
go away independent of the hang we are experiencing. I shall test and check in  
the fix tomorrow.

Comment 14

[Grace Bush]

see also bug 28207- where Create Profile Wizard runs twice

I reproduced this using first scenario...create profile, create IM screen name, 
exit (forced), relaunch and am required to create another profile 
Also reproduced without signing up IM

Comment 15

[Grace Bush]

adding myself to cc list

Comment 16

[selmer (gone)]

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

Comment 17

[racham]

Registry updates were missing. Fixed.

Comment 18

[scalkins]

I now get a crash exiting seamonkey on step 6 of the original testcase with 
Linux build 2000-02-22-12 M14. Talkback trace did not give any good info (TB 
#5755818) When I reenter seamonkey after the crash, I need to redefine the 
profile again, and re-setup AIM again also. Reopening.

Comment 19

[sairuh (rarely reading bugmail)]

drat, i was hoping that your linux crash (incident 5755818) would have the
same/similar trace as the one i experienced y'day (see bug 7799, and/or talkback
incident #5705971). poop.

Comment 20

[racham]

Crash seems to be corrupting the registry data...!

Comment 21

[scalkins]

AIM info is still not saved in the Linux Com rel build 2000-02-23-08 M14 this 
morning, but the mozilla profile is now being saved and I don't see a crash at 
exit now. 

Comment 22

[racham]

Please open a separate bug regarding aim data loss issue. Closing this bug now 
as worksforme.

Comment 23

[scalkins]

Verifying worksforme. Aim setup info not saved will be handled separately.

Comment 24

[scalkins]

AARRG, this is really still a problem on Linux. I verified that you cannot save 
the new mozila profile on 2 different machines with todays com rel build 
2000-02-23-08 M14) Sorry about the confusion.
1) Remove reg and profile from .mozilla folder
2)Launch seamonkey (./mozilla)
3)Create new profile. Launch seamonkey as that profile.
4)As soon as the browser appears and finishes the home page, select File-->Quit
5)Relaunch seamonkey (./mozilla)

Actual result: You are prompted for a new profile.
It seems in some cases, after creating the new profile, it actually will save 
the profile when you exit seamonkey if you browse in the browser to different 
web sites before quitting seamonkey. (I used different ones in the sidebar)

Comment 25

[racham]

I have fix for this. Tested  it on Linux. Need to check on other platforms. 

Comment 26

[selmer (gone)]

Bhuvan's fix isn't the one we need.  Dan tracked this down to the fact that 
libmozreg.so turned into libmozreg.a and got statically linked into both the 
xpcom and xpinstall shared libraries.  This results in all sorts of wackiness.  
The fix is now a one-liner in the xpinstall makefile to avoid linking in the 
libmozreg.a.  We can't check this in tonite, we'll get it in tomorrow - we want 
some exposure on the builds newsgroup to find out why this was changed and what 
impact there might be to the fix.

Comment 27

[racham]

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

Comment 28

[racham]

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

Comment 29

[selmer (gone)]

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

Comment 30

[Daniel Veditz [:dveditz]]

I'm going to reassign to myself, and change component to XPCOM Registry since 
the profile issues are really a side-effect of registry badness.

Comment 31

[Christine Begle]

Can we unconfidentialize this bug?  It's affecting mozilla builds, too.

Comment 32

[Daniel Veditz [:dveditz]]

Checked in.

Comment 33

[Alex Musil]

Sure, no need to be confidential.

Comment 34

[Daniel Veditz [:dveditz]]

fixed on Friday

Comment 35

[scalkins]

Verified Linux build 2000-02-28-08 M15

Comment 36

[selmer (gone)]

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

Comment 37

[Grace Bush]

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

Comment 38

[Grace Bush]

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