United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6540719 Firefox with JDK 6 will cause the browser to hang
JDK-6540719 : Firefox with JDK 6 will cause the browser to hang

Details
Type:
Bug
Submit Date:
2007-03-30
Status:
Resolved
Updated Date:
2010-09-17
Project Name:
JDK
Resolved Date:
2007-09-12
Component:
deploy
OS:
linux,solaris_nevada,windows_xp
Sub-Component:
plugin
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
solaris,6,6u1
Fixed Versions:
6u4 (b03)

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

Description
1) Install FireFox 2.0.0.3 with AdBlock plus plugin 
2) hit http://bbs.darktech.org/test2.html
3) Browser will hang

or just access the testcase mozilla folks provided:

http://bugzilla.mozilla.org/attachment.cgi?id=260034

Problem can be reproduced with the 1.6 JRE, but NOT the 1.5 JRE.

when it hang, breaking in the debugger given this stack:

#0  0x00a127a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xb7cc3404 in poll () from /lib/tls/libc.so.6
#2  0xb27abb18 in JavaVM5::ProcessWorkQueue ()
   from /usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so
#3  0xb27acf1d in JavaVM5::GetJavaObjectForInstance ()
   from /usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so
#4  0xb27a77d4 in JavaPluginFactory5::GetJavaObjectForInstance ()
   from /usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so
#5  0xb27a9de0 in JavaPluginInstance5::GetJavaObject ()
   from /usr/java/jre1.6.0_01/lib/i386/libjavaplugin_nscp.so
#6  0xb2809e5f in CNSAdapter_JavaPlugin::GetJavaObject ()
   from /usr/java/jre1.6.0_01/plugin/i386/ns7/libjavaplugin_oji.so
#7  0xb58634cc in nsHTMLAppletElementSH::GetPluginJSObject (this=0x8d73998, 
    cx=0x8a6fd60, obj=0x8d7b180, plugin_inst=0x8d46c28, plugin_obj=0xbfffc5ac, 
    plugin_proto=0xbfffc5a8) at
../../../../mozilla/dom/src/base/nsDOMClassInfo.cpp:9116
#8  0xb5862d38 in nsHTMLExternalObjSH::PostCreate (this=0x8d73998,
wrapper=0x8d72718, 
    cx=0x8a6fd60, obj=0x8d7b180)
    at ../../../../mozilla/dom/src/base/nsDOMClassInfo.cpp:8867
#9  0xb5438565 in nsObjectFrame::NotifyContentObjectWrapper (this=0xaf25e02c)
    at ../../../mozilla/layout/generic/nsObjectFrame.cpp:2173

So this is a hang inside the plug-in itself.

The only reason the adblock thing is relevant here is a timing
issue -- the JSobject wrapper for the object exists before the
plugin is instantiated.  You could get the same result without
adblock by having the <object> start out as display:none, and 
then from script toggling its display to "inline".  That should
hang as well, even if adblock is not installed.  Again, the key 
is that we ask the plug-in for its JSObject, and it hangs instead
of returning one... and that's not something we can fix in the 
browser.
 
Testcase that doesn't need adblock This hangs both trunk and
branch, whether adblock is installed or not, as expected.

                                    

Comments
EVALUATION

http://bbs.darktech.org/test2.html is basically the same as http://bugzilla.mozilla.org/attachment.cgi?id=260034, only that when loading the latter, the applet resource (MyApplet2.jar) is accessed via https.

The behavior seen on WinXP (FF & IE) and Solaris (FF) using 7.0b10 or 6.0_u2 b1 or 5.0u12 is as follow:

- Applet fails to load on all platforms and browsers regardless of the JRE version used. Received ClassNotFoundException:
load: class applet.Main not found.
java.lang.ClassNotFoundException: applet.Main
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:183)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:127)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:626)
	at sun.applet.AppletPanel.createApplet(AppletPanel.java:778)
	at sun.plugin.AppletViewer.createApplet(AppletViewer.java:2070)
	at sun.applet.AppletPanel.runLoader(AppletPanel.java:707)
	at sun.applet.AppletPanel.run(AppletPanel.java:361)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: open HTTP connection failed.
	at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:286)
	at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:44)
	at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:173)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:170)
	... 9 more

- However, with IE/Windows/any-JRE-version or with any-browser/any-platform/5.0u12, the browser doesn't hang afterward.

- With FF/any-platform/6.0u2b1-or-7.0b10, the browser hangs afterward.

The stack trace provided by Ingrid shows very normal plugin behavior on JPI/linux.
JavaVM5::ProcessWorkQueue() would loop always to prepare for non-LiveConnect JPI to browser communication.

Per inspecting the html page source for bbs.darktech.org/test2.html, the key for the problem is because applet.Main is detected for readiness during page load:
<BODY onload="document.getElementById('foo').style.display = ''">

To respond to this <BODY> tag, the browser sends a LiveConnect (JS->J) Applet.isActive() query while the applet is not yet loaded.
Between JRE5.0 and now, we may have probihit LiveConnect calls when Applet is not yet ready and hence the problem.

A temporary workaround while I look into a solution is to make sure applet.Main is a working applet and can be loaded.
                                     
2007-04-26
EVALUATION

In current java (latest updates as well as 7.0), we probihit LiveConnect calls when Applet is not yet ready (< APPLET_START). Since during page load, this testcase tries to detect for applet readiness (JS-J call) while the applet doesn't exist, and hence the behavior seen.

So this is not a problem, but rather it's a page error. It's okay to detect for applet readiness during page load, however, user should make sure that the applet exists and is loadable (in fact, passes APPLET_INIT).
                                     
2007-05-22
EVALUATION

Current behavior seen involves the applet loader thread when it's prohibiting stream of JS-J communication during applet loading. While we look into the solution, please have the user put in the suggested work around -- that is, to ensure that the detection applet.Main does exist, even if it's just a dummy applet.
                                     
2007-05-23
EVALUATION

I'm working on the fix. Fix is in review and when approved, will get it in to earliest possible update release.
                                     
2007-06-13



Hardware and Software, Engineered to Work Together