JDK-6540719 : Firefox with JDK 6 will cause the browser to hang
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: solaris,6,6u1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_nevada,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-03-30
  • Updated: 2010-09-17
  • Resolved: 2007-09-12
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.
6u10Fixed 7Fixed
Related Reports
Duplicate :  
1) Install FireFox with AdBlock plus plugin 
2) hit http://bbs.darktech.org/test2.html
3) Browser will hang

or just access the testcase mozilla folks provided:


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
#8  0xb5862d38 in nsHTMLExternalObjSH::PostCreate (this=0x8d73998,
    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 
Testcase that doesn't need adblock This hangs both trunk and
branch, whether adblock is installed or not, as expected.

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

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.

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).

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.