JDK-6672382 : Firefox hangs on Traditional Chinese & Japanese WinXP machine after 6u5 is installed
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6,6u4,6u5
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: generic,x86
  • Submitted: 2008-03-06
  • Updated: 2010-05-11
  • Resolved: 2008-03-18
Related Reports
Duplicate :  
User first reported the issue on this forum:
Affected systems:
   Windows (XP tested) localized in Traditional Chinese or Japanese
   Firefox 2 (FF tested)

 When loading an applet after jre installation, the browser hang (aka, pause, stop, halt)

WORK AROUND Another more automated way for this worksaround is to go to Java Control Panel, click on the "Advanced" tab, click on the second option "Java Console" to expand the options tree, choose the first option "display Java Console". In the future, when plugin is loaded, it will automatically open Java Console, and the crash does not appear.

EVALUATION Close this CR as duplicate of 6648381. SubCR has been created for 6648381 to back port this fix to 6u6.

EVALUATION In 6u5 (actually started since 6u4b1), when the AWT thread is busy creating the EmbeddedFrame and AppContext, Plugin's main thread pumps all events up and waits a max of 5 secs for EmbeddedFrame to get created. During the instantiation of EmbeddedFrame, FontConfiguration.getFontCharsetEncoder() tries to load the Charset(s) one by one. When encounters "Arial,ANSI-Charset" font with Charset name "default", since this Charset is not found on Asian locale system, this function wrongly tries to load <codebase>/default.class from the temp Plugin's ClassLoader. Since there's no such class exists, ClassLoader.findClass() takes a long time. The whole EmbeddedFrame creation process exceeds 5secs, and the EmbeddedFrame creation fails, leading to the plugin hangs problem seen. Fix is to not loading <codebase>/default.class when Charset name "default" is encountered in FontConfiguration.getFontCharsetEncoder(). It turns out, this problem has been fixed by Ken in 6u10 (see 6648381). The problem just manifests differently with 6u5 on Asian locale system. This webrev is exact the same as webrev for 6u10's 6648381. Spoke to Phil. He thinks it's safe for this fix to go in 6u6. Webrev sent.

EVALUATION I traced the problem to be a regression started since 6u4 build 1. The deadlock happens when creating the WNetscapeEmbeddedFrame. The problem is not reproducible with 6u10 b13. Looking at the plugin code surrounding the creation of EmbeddedFrame, between 6u4 b1 and 6u10 b13, we inverted the startup sequence of EmbeddedFrame and AppContext, so both are constructed in the same ThreadGroup. This is to avoid AWT/Swing window and focus events generated on the frame, being dispatched through the wrong EDT. However, only various "PARTIAL" of this inverting effort for EmbeddedFrame creation were checked in between 6u4 b1 and 6u5 b13 (on behalf of various bug fixes). I will continue to investigate the deadlock.

EVALUATION I can be able to reproduce problem on Minchi's system now, by not opening the Java Console.

EVALUATION I went to i18n-u20-1 system (VNC access provided by Minchi). Without doing anything to the system, and by just using the existing 6u5 and FF on the system, I do NOT have any issue loading/running any demo applets from: http://java.sun.com/products/plugin/1.5.0/demos/plugin/applets.html Every single demo applet from this site loaded and ran fine with 6u5 on this WinXP - Chinese locale system. If someone is able to reproduce the hang, please contact me and walk me through the session where the problem happens. Mickey Fan also reported the same problem with "applet hang" on Firefox after installing 6u5. I'm also awaiting for VNC access info from him.

EVALUATION Mickey's reported that all applets (including the government applet under http://www.gov.hk/en/residents/culture/recreation/facilities/leisurelink.htm and all java demo applets) hang when running with 6u5 and Firefox on WinXP Chinese locale system. There's no applet found under the governmental website that Mickey provided. The problem cannot be reproducible with java demo applet and 6u5 on local WinXP Chinese locale machine. The stack traces that Mickey sent do not show anything problematic. Contacted Mickey to ask for: 1) exact URL to government's applet. 2) Access to his XP machine where problem is reproducible. 3) Java console log files. Also contacted Min-Chi from SQE for access to a local test system where problem is "possibly" reproducible there.

EVALUATION removed evaluation of problem downloading and applying transform with firewall

WORK AROUND Open Java Console before lauching applets. If you open the Java Console before launching an appet, the browser will not hang. From the browser menu Go to Tools -> selcect "Java Console" or you can use IE. If that is an option for you.

EVALUATION This is clearly a P1 bug. Needs to be addressed ASAP.