United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6706305 JavaScript -> Java calls are being allowed against the applet too early
JDK-6706305 : JavaScript -> Java calls are being allowed against the applet too early

Details
Type:
Bug
Submit Date:
2008-05-22
Status:
Closed
Updated Date:
2010-11-03
Project Name:
JDK
Resolved Date:
2008-06-13
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b26)

Related Reports
Relates:
Relates:
Relates:

Sub Tasks

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
EVALUATION

fireAppletLoaded is issued before the applet init lock 
was aquired.
                                     
2008-05-23
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.
                                     
2008-05-23
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
                                     
2008-05-23



Hardware and Software, Engineered to Work Together