JDK-6742814 : In Java to JavaScript communication, JSObject.getWindow().call() locks up IE
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-08-29
  • Updated: 2013-01-10
  • Resolved: 2008-09-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 6
6u10 b32Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
JRE version 6 Update 10 (build 1.6.0_10-rc-b28)

ADDITIONAL OS VERSION INFORMATION :
Windows XP Professional, version 5.1, (2600.xpsp_gfe.070227-2300:Service Pack 2)

A DESCRIPTION OF THE PROBLEM :
When JApplet uses netscape.javascript.JSObject.call()-function, Internet Explorer 6 stucks. Javascript method eval functions normally. I use Microsoft Visual Web Developer 2008 to launch the aspx-page. The web page-applet system works normally in JRE 1.6.0_05 and also worked normally in JRE 6 update 10 build 14 (beta) before I updated to RC.


ACTUAL -
IE 6 gets stucked. Only Windows Task Manager can stop html-page.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.JLabel;
import javax.swing.JPanel;
import netscape.javascript.JSObject;//...jre/lib/plugin.jar

public class TestApplet extends javax.swing.JApplet{

    public void init() {
        try {
            java.awt.EventQueue.invokeAndWait(new Runnable() {
                public void run() {
                    System.err.println("Thread = " + Thread.currentThread());
                    initComponents();
                    startProgram();
                }
            });
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
    public void startProgram(){
            try {
                JSObject win = JSObject.getWindow(this);
                if (win != null){
                    win.eval("alert('Javascript Alert')");
                    win.call("FunctionX", null);// Call FunctionX() in HTML page
                }
            }
            catch (Exception ex) {
                System.err.println("This browser may not support Java to Javascript communication");
            }
    }
    
     private void initComponents() {
        JPanel jp = new JPanel();
        JLabel jl = new JLabel("This is JLabel");
        jp.add(jl);
        this.getContentPane().add(jp);
    }

   public void myFunction(){
            try {
                JSObject win = JSObject.getWindow(this);
                if (win != null){
                    win.eval("alert('I got the message')");
                }
            }
            catch (Exception ex) {
                System.err.println("This browser may not support Java to Javascript communication");
            }
    }
}

and html-page

<body>
<form id="form1">
<div>
<H1> Test Applet
</H1>
<br />

<script>
functionX(){
    document.TestApplet.myFunction();
}
</script>

<APPLET MAYSCRIPT CODE=TestApplet.class NAME=TestApplet archive="TestApplet.jar" WIDTH=100% HEIGHT=90%
</APPLET>
      
</div>
</form>
</body>
</html>
---------- END SOURCE ----------

Release Regression From : 6u7
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION This is a regression introduced late in the 6u10 cycle, likely by 6691927 in build 23 or 6706305 in build 26, but stemming back to 6663106 in build 13. The rules for initiating JavaScript-to-Java and Java-to-JavaScript calls (which will be formalized in the forthcoming new LiveConnect specification) are: - JavaScript-to-Java calls against a given applet block until that applet has completed init(), or - that applet initiates a Java-to-JavaScript call in init(). Barriers introduced with the above fixes were not obeying these rules, leading to classic deadlock between the browser and attached JVM instance in some situations. The fix is twofold: - If an applet makes a Java-to-JavaScript call in init(), allow JavaScript-to-Java calls to be made against it. - If a request comes to the browser from an applet to fetch the JavaScript window object corresponding to the applet, drain the queued up messages corresponding to JavaScript-to-Java calls, which would otherwise occur when init() was completed.
2008-09-04

SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u11/6742814.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_11/6742814/
2008-09-04