35384 - Each launch remigrates or asks for new account info...

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[laurel]

Using 2000-04-10-09m15 commercial build linux rh6.0


After migrating or creating a new profile, exit and relaunch causes remigration
or launch to mail setup wizard.

1.  Remove .mozilla directory containing registry and seamonkey user files.
2.  Launch apr10 commercial build using -installer.
3.  Profile automigrated. Go to mail, log into mail account (IMAP or POP), get
messages.
4.  Exit and relaunch.
    Result:  profile remigrates.
    Note:  prefs.js file is present and points to the ./mozilla mail files
properly.  I noticed there is a "registry" file present in both ./mozzilla and
the mail user's directory -- ?

1.  Remove .mozilla directory containing registry and seamonkey user files.
2.  Launch apr10 build without argument (./netscape)
3.  Go to mail window, mail setup wizared launches, fill in all information,
Finish.
4.  Login to mail account (IMAP or POP), get messages.
5.  Exit and relaunch.
    Result:  goes to mail account wizard again.

Comment 1

[racham]

Looks like bug 28243 is resurrected. 

Adding Dan Veditz to the cc list.

Sequence :
delete/rename ~/.mozilla/registry
Launch browser (./netscape).
CreateProfile. 
Exit. 
Launch browser (./netscape). 
CreateProfile Wizard comes up again.

Note :

* If create a profile second time when the wizard shows up that profile is 
saved.

* Happens only on Linux.

Comment 2

[Daniel Veditz [:dveditz]]

This is indeed bug 28243 resurrected.

MOZ_REGISTRY_LIBS was added to mozilla/extensions/psm-glue/public/Makefile.in 
by [e-mail] on 21 March. Because of VMS according to the comments.

MOZ_REGISTRY_LIBS was added to mozilla/xpinstall/src/Makefile.in by 
[e-mail] on 4 April. Because of OS/2 according to the comments.

libreg manages global data, it should not be included as a static lib multiple 
times. On Mac and Win it's a shared library, not sure why it was changed to a 
static library on unix.  

Ok guys, fight it out :-)

Comment 3

[Suresh Duddi (gone)]

It is static because xpcom on unix folds in libreg. No one else in the same 
application should ever link with libreg on unix. libxpcom.so has it.

Comment 4

[cls]

Ugh, my bad.  Not sure about VMS, but I know that the OS/2 team has converted at
least one static library to a shared one (libtimer).  Are there any other issues
like this one that we need to be aware of?  Adding revelant parties to CC.

Comment 5

[Phil Peterson]

PDT thinks this is dogfood- since we can just run the profile mgr twice the first time. But we'd like to fix this before beta2

Comment 6

[cls]

I'd like to get this fix back into M15 (despite the branch) because regressions
suck.  The fix for the xpinstall portion of the problem is really simple.  I
have no idea why psm-glue/public/Makefile.in would even need or be affected by
EXTRA_DSO_LDOPTS being defined under OpenVMS.

Comment 7

[cls]

Attachment: Put MOZ_REGISTRY_LIBS in a OS/2 & OpenVMS ifarch

Comment 8

[Colin Blake]

I have just verified that OpenVMS does NOT need to have MOZ_REGISTRY_LIBS in the 
link of xpinstall. Please remove OpenVMS from your proposed patch!

Comment 9

[Colin Blake]

The MOZ_REGISTRY_LIBS in extensions/psm-glue/public should be removed. In fact, 
the entire definition of EXTRA_DSO_LDOPTS should be removed since we don't link 
any code in here any more (there are only idl files in here).

I think that with the psm code moving around some when it first landed, this 
change ended up in the wrong Makefile.

If someone would like to make this cosmetic change, I'll approve :-)

Comment 10

[sobotka]

On OS/2 we originally built libreg as a DLL. Since we're now only building a 
static lib and pulling it into xpcom, there's probably no reason why we should 
need it here if the other platforms don't. Unfortunately, I can't very at the 
moment because I'm still cleaning up conflicts from an update yesterday 
morning. Huynh, could you please try removing it and seeing what happens?

Comment 11

[Huynh Trinh]

An OS/2 build without -llibmozreg_s  will certainly fail during link w 
the following errors:

nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_GetPath' : unresolved external
nsInstallPatch.o(..\..\..\xpinstall\src\nsInstallPatch.cpp) :  error 
L2029: 'VR_GetPath' : unresolved external
nsInstallDelete.o(..\..\..\xpinstall\src\nsInstallDelete.cpp) :  error 
L2029: 'VR_GetPath' : unresolved external
nsInstall.o(..\..\..\xpinstall\src\nsInstall.cpp) :  error L2029: 
'VR_GetPath' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_ValidateComponent' : unresolved external
nsInstallTrigger.o(..\..\..\xpinstall\src\nsInstallTrigger.cpp) :  
error L2029: 'VR_ValidateComponent' : unresolved external
nsInstallPatch.o(..\..\..\xpinstall\src\nsInstallPatch.cpp) :  error 
L2029: 'VR_Install' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_Install' : unresolved external
nsInstall.o(..\..\..\xpinstall\src\nsInstall.cpp) :  error L2029: 
'VR_Install' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_UninstallDestroy' : unresolved external
nsSoftwareUpdate.o(..\..\..\xpinstall\src\nsSoftwareUpdate.cpp) :  
error L2029: 'NR_ShutdownRegistry' : unresolved external
nsInstall.o(..\..\..\xpinstall\src\nsInstall.cpp) :  error L2029: 
'VR_UninstallCreateNode' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegClose' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_UninstallDeleteSharedFilesKey' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegAddKey' : unresolved external
nsInstall.o(..\..\..\xpinstall\src\nsInstall.cpp) :  error L2029: 
'VR_GetDefaultDirectory' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegGetKey' : unresolved external
nsInstallDelete.o(..\..\..\xpinstall\src\nsInstallDelete.cpp) :  error 
L2029: 'VR_InRegistry' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_InRegistry' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_GetVersion' : unresolved external
nsInstallTrigger.o(..\..\..\xpinstall\src\nsInstallTrigger.cpp) :  
error L2029: 'VR_GetVersion' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegGetEntry' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_GetRefCount' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_GetRefCount' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegSetEntry' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_SetRefCount' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_SetRefCount' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_GetUninstallUserName' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_UninstallAddFileToList' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegDeleteKey' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegEnumEntries' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegEnumSubkeys' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegDeleteEntry' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_UninstallEnumSharedFiles' : unresolved external
nsSoftwareUpdate.o(..\..\..\xpinstall\src\nsSoftwareUpdate.cpp) :  
error L2029: 'VR_SetRegDirectory' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_Enum' : unresolved external
nsInstallFile.o(..\..\..\xpinstall\src\nsInstallFile.cpp) :  error 
L2029: 'VR_UninstallFileExistsInList' : unresolved external
nsSoftwareUpdate.o(..\..\..\xpinstall\src\nsSoftwareUpdate.cpp) :  
error L2029: 'NR_StartupRegistry' : unresolved external
nsSoftwareUpdate.o(..\..\..\xpinstall\src\nsSoftwareUpdate.cpp) :  
error L2029: 'VR_Close' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_Remove' : unresolved external
nsInstallDelete.o(..\..\..\xpinstall\src\nsInstallDelete.cpp) :  error 
L2029: 'VR_Remove' : unresolved external
nsInstallUninstall.o(..\..\..\xpinstall\src\nsInstallUninstall.cpp) :  
error L2029: 'VR_UninstallDeleteFileFromList' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegGetUniqueName' : unresolved external
ScheduledTasks.o(..\..\..\xpinstall\src\ScheduledTasks.cpp) :  error 
L2029: 'NR_RegOpen' : unresolved external

Comment 12

[sobotka]

My guess is we're not exporting the symbols from libreg_s when creating 
xpcom.lib. If those do get linked into xpcom, then adding libreg_s to the 
.def-file creation routine there should eliminate the need for it here.

Comment 13

[Colin Blake]

Not exporting the symbols from libreg_s sounds like the problem. In the early 
days I had a lot of trouble on OpenVMS locating and exporting all the symbols 
for each .so file. I still don't have a clean solution. It sure would be simpler 
if each .so file had its own list of symbols to be exported.

Comment 14

[sobotka]

Setting up xpcom.lib to export the libmozreg_s symbols covers all the 
unresolved externals in Huynh's output, so OS/2 doesn't need MOZ_REGISTRY_LIBS 
for xpinstall either.

Comment 15

[cls]

Attachment: Back out additional MOZ_REGISTRY_LIBS added by cls & mwelch

Comment 16

[racham]

Not knowing why cls and mwelch added MOZ_REGISTRY_LIBS, I am passing on the bug 
to [e-mail] so that he can get the fix in and make sure the 
related changes still work (also mwelch).

I will verify profilemanager's behavior after the checkin.

Comment 17

[cls]

The second patch has been checked in.

Comment 18

[racham]

With cls's checkin (backout of additional MOZ_REGISTRY_LIBS), profilemanager's 
behavior is fixed. Information is getting saved in the registry as expected. 
thanks cls.

Laurel should do the actual verification and update the bug report.

Comment 19

[laurel]

With apr18 m15 and m16 commercial builds on linux rh6.0, both migrate and new
profile sticks around now.  

Is development going to do something further with this (I can't quite tell from
all the comments) or should we go ahead and mark this fixed?

Comment 20

[racham]

This bug addresses profilemanager problem (i.e., profile information not being 
saved, a side effect of MOZ_REGISTRY_LIBS addition), which is fixed now. 

Marking this fixed.

Comment 21

[laurel]

Marking verified

Comment 22

[leger]

Updating [beta2+] in Status Summary to [nsbeta2+]  In case this reopens, I need 
it on the right radar.

Comment 23

[Grace Bush]

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

Comment 24

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.