198166 - JRE 1.4.1 hangs browser when loading LiveConnect applet

Status: RESOLVED WORKSFORME

(Core Graveyard :: Java: OJI, defect)

Description

[William C. McCain]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

When JRE 1.4.1_02 is installed and a small (4.6K) signed applet is loaded, the
"Warning - Security" prompt appears, the user accepts the certificate, and the
applet runs correctly.  Under the same circumstances, when a larger (28.3K)
signed applet is loaded, the browser hangs after painting the frame of the
"Warning - Security" pop-up window.

At first I thought this might be an out-of-memory issue, but I retested with a
freshly booted PC (128M RAM), with no other applications loaded.  Same result,
browser hangs loading the larger applet.  After hanging, and while the browser
is still resident, the system Resource Meter shows 80% or more of all system
resources still free.

Occasionally (but not always) the Java Console displays
  java.lang.illegalArgumentException: null source
just before the browser hangs (the Java Console hangs too).  This suggest a
timing problem of some kind -- i.e., the JRE is attempting to execute a signed
applet before it has fully loaded (and before the user has accepted the signing
certificate).  And the timing problem could very well be related to the size of
the JAR file being downloaded from a web site.

Both the small and larger signed applets load and run just fine under Mozilla
(1.3) with JRE 1.4.0_01 installed.  Both applets also load and run perfectly
under Microsoft IE with EITHER JRE 1.4.1_02 or JRE 1.4.0_01.  So the problem is
a REGRESSION, and it is specific to JRE 1.4.1 under Mozilla (1.3).

Reproducible: Always

Steps to Reproduce:
1. Access my small signed applet test case at http://www.metaconnect.com/pt.htm.
 This works.  (When the Security Warning dialog pops up, click on "Grant this
session".)
2. Access my larger signed applet test case at
http://www.metaconnect.com/hostpubl/demos/gsdemo.html.  This hangs the browser.
 (The frame of the Security Warning dialog is painted, but that is as far as it
gets.)

Actual Results:  
Browser hangs.  Java Console hangs too.

Expected Results:  
The entire Security Warning dialog should be painted, the user should be able to
accept the signing certificate, and after that the applet should run.

Comment 1

[Joshua Xia]

Please use the latest JRE1.4.2-beta, Thanks!

Comment 2

[dsirnapalli]

-- Verified in the latest trunk build on Win2K with JRE1.4.1_02. Browser is
hanging when loading larger signed applet.

Comment 3

[Michael Dunn]

Need traction on this bug

Comment 4

[Jack Lu]

Joshua,

Would you file a bugtraq bug for this and assign to Java Plug-in team? Thanks.

Comment 5

[Jack Lu]

This bug is a duplicate of bug 197759 which we won't have a solution in short 
term. The workaround is to call "getWindow" in the applet "start" method 
instead of "init" method.

Comment 6

[William C. McCain]

There is no explicit call to "getWindow" in the applet "init" method (or 
anywhere else in the "large signed applet" that hangs).  Not likely it is doing 
anything that makes an indirect call to "getWindow", either.  These applets use 
no Frame or Window objects, they run entirely in the "Web page sandbox".  No 
WindowEvent objects are handled explicitly anywhere in these applets.

Comment 7

[Jack Lu]

"thread applet-sx.class" prio=4 tid=0x02a78450 nid=0x4d8 runnable [206ff000..206
ffd94]
        at sun.plugin.javascript.navig5.JSObject.JSGetNativeJSObject(Native Meth
od)
        at sun.plugin.javascript.navig5.JSObject.JSGetNativeJSObject(Unknown Sou
rce)
        at sun.plugin.javascript.navig5.JSObject.<init>(Unknown Source)
        at sun.plugin.viewer.context.NetscapeAppletContext.getJSObject(Unknown S
ource)
        at netscape.javascript.JSObject.getWindow(Unknown Source)
        at sx.init(sx.java:653)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

The above is the stack shown during my test. The Applet class sx call getWindow
in Line 653.

Comment 8

[William C. McCain]

Okay, there was some confusion on my part about WHICH "getWindow" you meant.  
The only "getWindow" documented in the Sun Java API is related to WindowEvent 
objects -- that is the "getWindow" I thought you meant, and (as I said) THAT 
"getWindow" is never called.

The "getWindow" shown in your trace is associated with Netscape's JSObject API 
-- in other words, the LiveConnect API.  Indeed, the applet DOES call 
"JSObject.getWindow", and that call is essential to the applet's operation.  The 
applet makes EXTENSIVE use of LiveConnect.

It might be possible, but with GREAT difficulty, to redesign the applet to do 
its LiveConnect initialization in the "start" method rather than the "init" 
method.  However, I no longer have this option.  This applet, and numerous ones 
similar to it, were developed several years ago for my former employer, from 
whom I retired in 1999.  I no longer have access to their source code or the 
ability to make changes to their products.

Please note that this problem is a REGRESSION -- it worked fine in all Java 
releases through and including 1.4.0.  It fails only in JRE 1.4.1, and then only 
under the Mozilla browser (it works in Microsoft Internet Explorer with JRE 
1.4.1).

Comment 9

[Joshua Xia]

This bug is filed in Sun's bugtraq #4856057

Comment 10

[William C. McCain]

The title of this bug should be changed to "JRE 1.4.1 hangs browser when loading 
LiveConnect applet", as I now realize the true nature of the problem.  The 
applet's size, and being a signed applet, apparently had nothing to do with it 
-- these were "red herrings".

I do apologize for not doing better "problem isolation".  Indeed, before 
retiring I spent 30 years as a software engineer for major software vendors in 
Silicon valley, and I very well know how important it is for the tester to 
correctly identify the test conditions that are truly relevant (in this case, 
LiveConnect) and to NOT specify test conditions that are irrelevant ("red 
herrings").

Now that the true cause of the bug is known, I feel obligated to point out that 
the problem probably impacts practically every LiveConnect applet ever written.

Comment 11

[Samir Gehani]

adt: nsbeta1+/adt2

Comment 12

[Joshua Xia]

this bug also happen on IE + JRE 1.4.2-beta-b19
so it should be JRE/JPI 's bug.

unblock 1.4.

Comment 13

[Xiaobin Lu]

We have fixed it in JRE 1.5 release. The Sun internal bugtraq bug no is 4821301.

Comment 14

[Kyle Yuan]

not a mozilla bug. fixed in jre 1.5.