JDK-6631506 : REG : Unable to launch an applet on MZ using 6u4
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u4
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2007-11-19
  • Updated: 2010-09-08
  • Resolved: 2007-11-21
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 Availabitlity Release.

To download the current JDK release, click here.
Other JDK 6
1.4.2_17Fixed 6u4 b09Fixed
Related Reports
Relates :  
REG : Unable to launch an applet on MZ

Tested Bundles : 6u4 b06, b07, b08
Tested OS : Windows xp, Vista

steps to reproduce :
1. install jre
2. clear cache and remove deployment.properties file
3. launch any applet on mozilla (tested version 1.7.8)

The applet is not loaded. the browser is not detecting the java plugin
Note : The applets are running fine with IE and FF

It is a regression from 6u4 b06. It is working fine in 6u4 b05.

EVALUATION No crash is involved. Problem is with plugin libs failed to load. Root cause: 1) First LPTSTR commandLine = ::GetCommandLine(); results in a ill-formatted cstring that could not accept by GetLongPathName() in getMozVersion(). The commandLine contents is ""C:\Program Files\mozilla.org\Mozilla\mozilla.org" ". The extraneous double quotes and space and the single '\' caused GetLongPathName() to fail with error 123 (illegal input parameter). By replacing GetCommandLine() with GetModuleFileName(), GetLongPathName() is happier. 2) HKLM/software/Mozilla/Mozilla 1.8b/bin/PathToExe=C:\Program Files\mozilla.org\Mozilla\*m*ozilla.org HKLM/software/Mozilla/Mozilla 1.7.13/bin/PathToExe=C:\Program Files\mozilla.org\Mozilla\*M*ozilla.org while longPathName="C:\Program Files\mozilla.org\Mozilla\*m*ozilla.org" The case sensitive comparison in line 87 of the old code fails for 1.7.13.

SUGGESTED FIX http://web-east.east/deployment/www/webrevs/ccheung/1.6.0/6631506/

EVALUATION This is a regression introduced by the fix for 6620045 in 6u4 b06. FF changes the registry entries from time to time. This was the main reason for 6620045. The fix for 6620045 includes a non-trivial function to determine the Moz. version from the registry and unfortunately introduces this regression. Since the current java plugin uses the same NS7 adapter to work with both Moz. and FF browsers. A simpler fix is to default to the NS7 adapter if reading of some of the registry entries has failed while in the process of determining the Moz. browser version. The new fix addresses both the issues in this bug and 6620045.