27462 - OJI is initialized and shutdown incorrectly if Profile Dialog is shown at startup

Status: VERIFIED WORKSFORME

(Core Graveyard :: Java: OJI, defect, P3)

Description

[stanley.ho]

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.

Comment 1

[edburns]

Taking ownership.

Comment 2

[edburns]

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.

Comment 3

[edburns]

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

Comment 4

[drapeau]

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

Comment 5

[leger]

Putting on PDT+ radar for beta1.

Comment 6

[edburns]

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

Comment 7

[leger]

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

Comment 8

[edburns]

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.

Comment 9

[edburns]

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?

Comment 10

[drapeau]

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

Comment 11

[leger]

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

Comment 12

[Paul Wyskoczka]

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

Comment 13

[edburns]

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.

Comment 14

[edburns]

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

Comment 15

[Mike]

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

Comment 16

[edburns]

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

Comment 17

[Paul Wyskoczka]

Changed QA contact

Comment 18

[Gervase Markham [:gerv]]

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

Comment 19

[Jeff Dyer]

Reassigning to Joe

Comment 20

[Joe Chou]

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

Comment 21

[shrirang khanzode]

cleaning up resolved bugs..Verif wfm on 0802 trunk