JDK-6706305 : JavaScript -> Java calls are being allowed against the applet too early
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-05-22
  • Updated: 2010-11-03
  • Resolved: 2008-06-13
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 Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b26Fixed
Related Reports
Relates :  
JDK-6691927 - Java console goes blank when opened from Java Tray icon in case of IE6
Relates :  
JDK-6742814 - In Java to JavaScript communication, JSObject.getWindow().call() locks up IE
Relates :  
JDK-6663106 - JNLP applet re-launch freezes FF3 due to pending LiveConnect messages
Description
In discussions with ###@###.###, it is clear that the initial JavaScript -> Java call against an applet is being allowed to go through too early. The implicit semantics, which are long-standing, are that the first JS -> Java call is only allowed to be executed once the applet has completed its init() method, unless the applet first makes a Java -> JS call. The fact that fireAppletLoaded() in the Plugin2Manager releases the LiveConnect message queue on the browser side before init() is called is introducing regressions in test cases. This needs to be corrected urgently. It is very likely related to the recent email thread around calls to isActive() causing errors in the IE JavaScript engine.
Please contact ###@###.### for test cases that do JS -> Java calls and which do not behave correctly without a workaround (calling Applet.isActive()) to prevent the JS -> Java call from going through too early.
Comments
SUGGESTED FIX 6706305 JavaScript -> Java calls are being allowed against the applet too early [ Kenneth Russel ] fireAppletLoaded is issued before the applet init lock was aquired. This regression was introduce with CR 6691927, where I have moved fireAppletLoaded above the init lock to allow browser messages to come through earlier. +++ JREInfo: The list is ordered with the highest product version as the first element and declining. Otherwise LaunchSelection would fetch an arbitrary JREInfo version, and not the latest one available. JVMManager: Handling VersionString, which may contain more than one VersionIDs for the JREInfo selection algo. This is mandatory, since JRESelectionException passes the JREDesc VersionString. +++ testcase: http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/ALC/PrintThread.html http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6675834/ http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6680615/ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6706305.0/ workspace: deploy engineer: sven.gothel
23-05-2008
EVALUATION This regression was introduce with CR 6691927, where I have moved fireAppletLoaded above the init lock to allow browser messages to come through earlier.
23-05-2008
EVALUATION fireAppletLoaded is issued before the applet init lock was aquired.
23-05-2008