From Bug Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) BuildID: 1999122808 When Mozilla starts and the profile dialog shows up (nsProfile::LoadDefaultProfileDir), it will trigger OJI to start automatically and call nsIJVMPlugin::Initialize(). When the profile is closed, nsIJVMPlugin::Shutdown() is called because there is no other outstanding nsWebShell window around (the main Mozilla window is not created yet). After that point, nsAppRunner will try to create the main Mozilla window. However, because OJI has been started, nsJSEnvironment in LiveConnect will cache the nsIJVMPlugin around. Thus, when we try to run an applet using the APPLET tag, the browser thinks the OJI has been started and initialized properly, and nsIJVMPlugin::CreateInstance() will be called, without calling nsIJVMPlugin::Initialize() again. This is pretty bad because it confuses the OJI plug-in (it will not create any instance if it has not been re-initialized again) and it will not be able the create an Java plug-in instance properly. I am able to reproduce this bug all the time with a Debug build of Mozilla. With a release build of Mozilla, the profile dialog is not shown up for some reasons, so the bug doesn't show up. Reproducible: Always Steps to Reproduce: 1. Create more than one profiles. 2. Compile Mozilla with MOZ_DEBUG=1 3. Install latest Java Plug-in from Sun (02/01/2000 build) 4) Start Mozilla, and profile dialog will come up 5) Select one of them and then Mozilla window will be shown 6) Open a URL that contains the APPLET tag in a HTML page 7) No applet is shown in the page. This bug is related to starting/stopping LiveConnect in the browser, and it confuses the lifecycle of the OJI plug-in. This bug prevents us to do any debugging with Mozilla, because Java Plug-in will now only works with Release build of Mozilla.

Taking ownership.

Excellent analysis, Stanley. Next time, though, It would be helpful to include the Java Plugin source file names. For the record, here's the stack trace of when it gets shut down pre-maturely: CJavaPluginFactory::Shutdown(CJavaPluginFactory * const 0x006655ac) line 276 nsPluginHostImpl::Destroy(nsPluginHostImpl * const 0x01c14e24) line 1429 nsWebShell::DestroyPluginHost() line 551 nsWebShell::~nsWebShell() line 656 nsWebShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsWebShell::Release(nsWebShell * const 0x01c14a00) line 709 + 152 bytes nsCOMPtr<nsIBaseWindow>::~nsCOMPtr<nsIBaseWindow>() line 435 nsWebShellWindow::~nsWebShellWindow() line 233 nsWebShellWindow::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsWebShellWindow::Release(nsWebShellWindow * const 0x01c39580) line 238 + 134 bytes nsCOMPtr<nsIWebShellWindow>::~nsCOMPtr<nsIWebShellWindow>() line 435 nsProfile::LoadDefaultProfileDir(nsCString & {...}) line 317 nsProfile::StartupWithArgs(nsProfile * const 0x00d588c0, nsICmdLineService * 0x00d25150) line 233 + 12 bytes main1(int 1, char * * 0x00ca4610, nsISplashScreen * 0x00000000) line 520 + 41 bytes main(int 1, char * * 0x00ca4610) line 677 + 17 bytes mainCRTStartup() line 338 + 17 bytes KERNEL I'm looking into how to affect a fix for this now.

Stanley, When you talk about nsIJVMPlugin::Initialize, are you talking about JavaPluginFactory::Initialize()? I'm finding that this method DOES get called twice. Once during the Profile Manager phase, and again, when a page with an applet is loaded. Even so, I'm not seeing the applet, just the grey box. Please answer my question about whether or not I have the right Initialize method. Thanks, Ed

Adding beta1 to keywords since Java working in Mozilla depends on this.

Putting on PDT+ radar for beta1.

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

Must fix by 03/03 or you will miss the beta1 train.

Stanley has a workaround on the JPI side. Will verify tomorrow. If it works, we don't need to fix this until after the beta.

Stanley's workaround works, when you build without MOZ_DEBUG set. I want to leave this open, but I want to indicated that it must be fixed AFTER beta. How do I do that?

Check out Ed's last comment; please re-evaluate. Any questions? Ask Ed or me!

Puttingn on PDT- radar. paw, can you get us Release Note text in http://bugzilla.mozilla.org/show_bug.cgi?id=25524 please?

Stanley or Ed, can you send me your most recent jre 1.3 for testing. Thanks.

I'm adding the STANLEY_WORKAROUND status word, so we know that this is a bug that Stanley has worked around. I'm also reassigning this to Jeff Dyer.

Stanley's workaround removes the Stability blocker status. Moving to M16.

M16 has been out for a while now, these bugs target milestones need to be updated.

The default profile prevents this bug from manifesting. Need testcase.

Changed QA contact

It seems unclear to me whether this bug requires either of a "developer" or "user" release note for Netscape 6 RTM. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-devel strings in the Status Whiteboard. Thanks :-) Gerv

Reassigning to Joe

Tested with recent trunk build and JRE 1.3.1, on Unix and Windows. It worked for me.

cleaning up resolved bugs..Verif wfm on 0802 trunk