Spinoff of bug 400467 for the underlying issue. Java on Windows does not work when the HKLM\Software\mozilla.org\Mozilla\CurrentVersion registry value is not present and applications won't be able to add this value when the user doesn't have write access to HKLM. http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/src/nsPluginDirServiceProvider.cpp#374 There is a bug filed with Sun for this issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6620045 IMO the ideal solution would be for Java to get this information directly from the application it is running as a plugin in instead of from an external source such as the registry. As it stands now the version info will not be correct if for no other reason than the Java plugin can be used by multiple applications that have different GRE versions on the same system and getting the version from the application would always provide the correct version. If for some reason an external source for the version is required then at the very least it should read it from HKCU first and if that doesn't exist then from HKLM. This is not by any means a good solution since the GRE version information would be incorrect under many scenarios as mentioned above. Also, does Java get the version from an external source for Mac OS X / Linux and if it does where does it get this information?
> IMO the ideal solution would be for Java to get this information directly from > the application it is running as a plugin in instead of from an external source > such as the registry. FYI. As I mentioned in Bug 400467 Comment #14, reason why Sun Java uses external source is possibly crash in Java plugin when modified User Agent string(Bug 83376). The crash of Bug 83376 is not reported for newer Java plugin. But, crash of your Bug 400467 Comment #21(correct format but different version is set) sounds similar crash to Bug 83376 for me.
Possibly but as noted the value they get from the registry will likely be incorrect if multiple Gecko based apps are run on the system and it doesn't seem that the same is necessary for Mac OS X / Linux though the same is true for these platforms and the value doesn't seem to matter. Also, if the version is truly needed there are other methods available to get this info reliably as of 1.8 that could be tried first and then fallback to reading the registry or whatever.
Kenneth, is this something you know anything about? Is this an issue even in the new upcoming Java plugin? If so, we should talk about what can be done about this...
Danielle.Pham@sun.com is the responsible engineer for the Sun bug 6620045. I don't know much about the code in question on either the browser or Java Plug-In sides, but searched through the Java Plug-In code and there are no attempted writes of these registry keys. It does look like the problematic code is what is pointed to above in nsPluginDirServiceProvider.cpp. I can see from looking at the Java Plug-In sources that the current OJI-based Java Plug-In will still be broken if the write of the registry key is removed, since it expects to query CurrentVersion and find a value there. It's using that value to figure out whether it's running on an older or newer browser type. Realistically, it could have better default behavior, but the fact is that the current code doesn't. The new NPRuntime-based Java Plug-In would not be affected if the registry key write of CurrentVersion were removed from nsPluginDirServiceProvider.cpp, as it doesn't query this registry key. However, it is relying on the search that this code does to find the Java Plug-In in the currently installed JREs.
The problem was mis-reported and is actually due to the requirement that the CurrentVersion reg name / value pair exist under HKLM. A workaround to this has been landed for Firefox 126.96.36.199. If there will be new versions that are not based on the new NPRuntime-based Java Plug-In it may be worthwhile to include a fix for this requirement to have this reg value present.
Is there a link to the patch which was applied for 188.8.131.52? We believe at this point that the real problem is that the current OJI-based Java Plug-In doesn't have good fallback behavior if the HKLM CurrentVersion key doesn't exist. The failures to write the registry key in nsPluginDirServiceProvider.cpp do not directly cause the failure. Rather, the absence of this specific registry key breaks the current Java Plug-In upon its startup. We are testing a fix for this problem under Sun bug ID 6620045 and will put it back for a future version of the OJI-based Java Plug-In regardless.
The problem was due to Vista's knit pick on JPI reading (not writing) of registry value HKLM\Software\mozilla.org\Mozilla\CurrentVersion upon startup. JPI reads this value to make sure Mozilla is of adequate version before startup. This code has not been changed from JPI side, so FF184.108.40.206 must have done something such that it raise the Vista's security level checking when reading this value. Anyway, I'm the mid of working on a fix. Will try to get fix in to the nearest JRE 6 update slot. Meanwhile, Robert, I really appreciate if you could put a workaround in FF 220.127.116.11.
Ah, I see, this key value is missing on Vista but is still there on XP, and that's why JPI reads of this key is having problem. I will work on a fix for JPI side. Please also put a workaround in FF18.104.22.168. Thanks.
I landed the workaround for 22.214.171.124, 126.96.36.199 and on the trunk in bug 400467. The patch adds the current GRE Version to HKLM\Software\mozilla.org\Mozilla\CurrentVersion whenever software update runs or Firefox is installed via the installer. It won't cover all cases (e.g. user installing without write access to HKLM) but it should cover the vast majority of them. btw: the key won't be there on XP, Win2K, etc. if the user installing Firefox doesn't have write access to HKLM.
For the sake of posterity... The problem (as noted by Danielle) is due to there note being a registry value for HKLM\Software\mozilla.org\Mozilla\CurrentVersion. This is not authoritative but I believe that for XP and below a greater number of users run as admin whereas for Vista these same users tend to run as admin with UAC turned on. This is why it worked most of the time in XP and below and we have found reports in the support forum along with a workaround of running Firefox with an account in the administrators group and then loading a Java applet to workaround this problem. Before 188.8.131.52 we did not include an application manifest for Firefox so registry virtualization occurred on Vista so reads / writes to this registry entry would be redirected to the registry's VirtualStore. With 184.108.40.206 Firefox includes an application manifest so virtualization no longer occurs and this bug becomes more prevalent.
Fix on JPI side will be available in JRE 6.0 update 5. JPI will not rely on this key anymore for any Windows platform.
FYI. Java Plugin fix was able to make it in a bit earlier: to JRE 6 update 4.
Thanks Danielle. I suspect it would just be a guess but any idea on when that will be released?
(In reply to comment #10) > Before 220.127.116.11 we did not include an application manifest for Firefox so What exactly is this application manifest? Do you have a CVS link or will it be generated at install/startup? If should I look for it? I mean, SeaMonkey v2.0a seems to pick up more and more Mozilla Firefox code/changes, but I'm not sure in this case. Might this also affect SeaMonkey / Vista users who reply on Java for their business applications?
The info is available in bug 400467 comment #11