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
calls returning void were causing a NullPointerException to be thrown
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
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
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
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.