Bug ID: 6742814 In Java to JavaScript communication, JSObject.getWindow().call() locks up IE

6742814 : In Java to JavaScript communication, JSObject.getWindow().call() locks up IE

Details

Type:	Bug	Submit Date:	2008-08-29
Status:	Closed	Updated Date:	2013-01-10
Project Name:	JDK	Resolved Date:	2008-09-29
Component:	deploy	OS:	windows_xp
Sub-Component:	plugin	CPU:	x86
Priority:	P2
Resolution:	Fixed
Affected Versions:	6u10
Fixed Versions:	6u10

Related Reports

Relates:	JDK-6675834 - (Nightly) : Some of the Liveconnect scenarios are making browser to hang when run with new Plug-in
Relates:	JDK-6706305 - JavaScript -> Java calls are being allowed against the applet too early
Relates:	JDK-6663106 - JNLP applet re-launch freezes FF3 due to pending LiveConnect messages
Relates:	JDK-6727020 - Intermittent reliability problems related to applet relaunching
Relates:	JDK-6691927 - Java console goes blank when opened from Java Tray icon in case of IE6

Sub Tasks

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

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

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

SELECT A COUNTRY/REGION
Africa Operation Argentina Australia Austria Bahrain Bangladesh Belgium & Luxembourg Belize Bhutan Bolivia Bosnia & Herzegovina Brasil Brunei Bulgaria Cambodia Canada - English Canada - French Chile China Colombia	Costa Rica Croatia Cyprus Czech Republic Denmark Ecuador Egypt Estonia Finland France Germany Greece Guatemala Honduras Hong Kong Hungary India Indonesia Iraq Ireland	Israel Italy Japan Jordan Kazakhstan Korea Kuwait Laos Latvia Lebanon Lithuania Malaysia Maldives Malta Mexico Moldova Nepal Netherlands New Zealand Nicaragua	Norway Oman Pakistan Panama Paraguay Peru Philippines Poland Portugal Puerto Rico Qatar Romania Russia Saudi Arabia Serbia & Montenegro Singapore Slovakia Slovenia South Africa Spain	Sri Lanka Sweden Switzerland -- French Switzerland -- German Taiwan Thailand Turkey Ukraine United Arab Emirates United Kingdom United States Uruguay Venezuela Vietnam Yemen

Hardware and Software, Engineered to Work Together