Webclient will crash if the user has more than one mozilla profile defined.

THis is a dup of bug 60246 which was reported on SUN solaris

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

Fix checked in.

Hi Ed, This fix has an inherent problem in that it tries to launch Mozilla with the "default" profile. If the user choose to name his profile anything other than "default" when he first launches Netscape 6/Mozilla, this fix in Webclient will cause a null ptr dereference and a core dump. I have tried this on Win32 and Solaris with similar results. If this happens the user would be forced to create an additional profile named "default" Rather than assume that a "default" profile exists, we could just ask users to have a single profile while using Webclient 1.0. This would be much easier for the users. So I would suggest that we withdraw this fix. thnx _Ashu

Ashu, I agree with your suggestion. In the end, I think it's an embedding bug. I'm going to update the relnotes to say you must have a profile called "default" without the quotes. I'll re-open the bug and assign it to embedding.

I meant to re-open this.

Ed, Pls review the patch posted. This fix checks to see if multiple profiles exist. If they do, it gets a list of all existing profile names and uses the first one in the list. This fix will always work whatever the names of the profiles the Webclient users have on their machines. This is a temp fix, but the code can be easily extended using your prompt mechanism to throw a dialog and allow the user to choose whatever profile he wants. Pls let me know if I have ra for this fix. If I do, then assign this bug to me and I will create the more elaborate profile selection mechanism later. thnx _Ashu

Hey, right on, this looks good. Let me test it out. If it works, we'll put it in the Webclient 1.0 release. I was thinking along these same lines, but had given up on it for 1.0.

I've tested this on Linux and it works. I've checked it in, but will leave it open so we can track this issue.

Ashu, is this still a bug with you new nsIProfile fix?

The nsIProfile work (with BlackConnect) does not affect this at all. Unfortunately, the way Webclient is designed, we cannot get access to the other interfaces (including ProfileManager) until the BrowserControlCanvas is added to the frame and rendered. And this involves the profile selection code we had worked on some time back. If this bug is showing up again, maybe we will need to fix it again on the native side.

Hi Ed, There was a small error in the modifications you made to my patch before checking it in. The char * temp was not being appended with a '\0' which was causing this to crash if multiple profiles existed. I have fixed this and am pasting the patch below. It's a very small change. Pls let me know if I can check this in. thnx much ------------------FIX--------------------- Index: NativeEventThread.cpp =================================================================== RCS file: /cvsroot/mozilla/java/webclient/src_moz/NativeEventThread.cpp,v retrieving revision 1.27 diff -u -r1.27 NativeEventThread.cpp --- NativeEventThread.cpp 2001/04/28 00:53:19 1.27 +++ NativeEventThread.cpp 2001/06/01 22:00:52 @@ -522,6 +522,7 @@ temp[i] = (char) Names[0][i]; } nsMemory::Free(Names); + temp[i] = '\0'; argv[2] = temp; argc = 3; } ------------------END FIX------------------------

ra=edburns

fix checked in. closing bug.

Verified with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010915 and latest Webclient. Mark verified.