United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6647070 JSObject reference counting problem
JDK-6647070 : JSObject reference counting problem

Details
Type:
Bug
Submit Date:
2008-01-04
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-01-29
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b11)

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
User jasuha1 on the java.net forums has reported a problem with the scoping of JSObjects. The attached test case loads the same web page three times in separate iframes. Each applet instance fetches the JSObject associated with the surrounding window. One of the iframes is then destroyed. The JSObjects associated with the other applet instances have then been invalidated.

This is a regression compared to the old Java Plug-In.

There is clearly a problem in the distributed reference counting scheme used by the shared LiveConnect code.

Links to associated forum threads:
http://forums.java.net/jive/thread.jspa?threadID=34807&tstart=0
http://forums.java.net/jive/thread.jspa?threadID=34805&tstart=0
The attached test case also crashes the Firefox 3 port of the new Java Plug-In if it is the first applet launched in the browser session. This must also be investigated.

                                    

Comments
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u10/6647070.0
testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6647070/
                                     
2008-01-05
EVALUATION

This test case from user jasuha1 on the java.net forums uncovered
several unrelated problems in addition to the underlying bug. The
first and most obvious of these was a crash in Firefox 3 during
loading of the test case. This was a regression caused by the
introduction of the call to the Java Kernel's preJVMStart() in
6644857. In a development build with no rt.jar, this call will pop up
a Windows message box indicating that rt.jar could not be found. While
the dialog box is up, messages are being pumped, and it turns out that
this causes the browser main thread in Firefox to continue
initializing other elements on the web page. Halfway through the
initialization sequence of the first applet, the second one starts
initializing. This causes the Java Plug-In's code to be called in an
unexpectedly reentrant fashion and initialization to be performed out
of order. Partial workarounds for this problem were added to the
InitializeJVM() call in JavaVM.c and some of the plugin's code in
MozPluginExports.cpp. Note that these changes are only a partial
workaround and that the best workaround for this problem lies in the
Java Kernel. 6647430 has been filed to further track this issue.

The second problem was a regression introduced with the fix for
Java/JavaScript null value handling in 6644253. Java-to-JavaScript
calls returning void were causing a NullPointerException to be thrown
during unmarshaling of the return result from the JavaScript engine.
Added a needed null check to the client-side LiveConnectSupport class
and proactively added a null check to the ArgumentHelper class which
is not currently called.

The third problem was a regression in the browser-side heartbeat code
(added in 6609036) which was introduced with the fix for 6613373
related to handling of invalid command-line arguments. The initial
ping in PluginMain was being sent back to the browser too early, and
in some cold start scenarios when the browser sent the SetJVMIDMessage
to the attached JVM, the call to Applet2Environment.initialize() took
so long that the browser would kill the attached JVM instance. Changed
PluginMain to send the message back to the browser later, after all of
the one-time initialization of the attached JVM is done.

After all of these other fixes, the underlying bug was remarkably
small. The browser-side LiveConnectSupport class keeps track of which
JavaScript objects have been exposed to the currently running applets.
The comments in the code indicate that these objects are tracked on a
per-applet basis. Unfortunately, the HashSet in the class tracking
these objects was a static variable instead of an instance member.
This meant that if any applet was destroyed, all existing JSObjects
for any running applets, even in other browser windows, would be
invalidated, breaking Java->JavaScript communication. This is a
staggering bug that it is astounding was not found by our testing
before now. A big thanks to the submitter for the excellent test case.

This only fixes the problem of incorrect JSObject invalidation. There
is another problem in the submitter's original test case only with the
new plug-in on Firefox 3 where JavaScript calls initiated from an
NPRuntime plug-in can not cross the frame boundary. This is a browser
bug and has been filed on http://bugzilla.mozilla.org as 410853:
https://bugzilla.mozilla.org/show_bug.cgi?id=410853 . See the test
case attached to that bug for a user-level workaround; unfortunately
no workaround is possible in the Java Plug-In.
                                     
2008-01-05



Hardware and Software, Engineered to Work Together