Java Installer fails to update/register CurrentVersion and BrowserJavaVersion registries correctly during installation and uninstallation of JRE 6 update when there's an existing installation of 5uN on the system.
Failure to update BrowserJavaVersion registry correctly is what causes the problem originally reported in this bug.
NOTE: The original bug synopsis is not correct. We do NOT want to copy any plugin libraries to any place for Firefox.
So I changed the bug synopsis to reflect the issue appropriately, and so that fix for both registries can be carried out all in one shot of webrev and putback (also to save extraneous paperwork).
Here's explanation for root cause:
- CurrentVersion issue root cause:
Problem is because InstallDeployToolkit() fails to do CopyFile() safely.
Consider case 5uX and 6uN are installed. During uninstallation of 6uN, ReregisterCurrentJRE() is called to re-establish all settings for 5uX, including its registries.
InstallDeployToolkit() is also called on 5uX. As part of this activity, toolkit's libs are copied from <jre>/bin/ to either <system_dir>/ or <FF>/plugins/ (for IE and FF, respectively).
Since 5uX doesn't have toolkit, the CopyFile() operation fails and so does the CanonicalizeJava2Registry() operation which restores 5uX registry settings.
The fix I chose is to ensure the CopyFile() operation operating gracefully by ensuring that the file source (toolkit's libs) exists before carrying out the CopyFile().
This simple fix in RegInstall.cpp is safe as it doesn't change the installer code dramatically and yet it corrects the problem with CurrentVersion registry.
- BrowserJavaVersion issue root cause:
The problem with BrowserJavaVersion key is not a regression in our code, rather it is caused by changes in Mozilla's treatments for its registries which we depended on:
1) Latest FF's value for "Install Directory" key now contains no trailing '\'
2) Registry tree Firefox 3 beta has the name Minefield, while we are looking for tree name "Mozilla Firefox"
3) Registry tree for Firefox 3 beta (Minefield) has the structure for Mozilla browser's registry structure, and therefore, it's treated as Mozilla browser instead of Firefox by our code. This causes our installer code fails to locate the real Mozilla browser if it also exists on the system.
During JRE installation and uninstallation, we depend on these registries to determine the existence of FF or Mozilla, and to register/unregister JRE with the browser. Setting BrowserJavaVersion is part of this process. With these Mozilla's registries messed up, so of course there goes our update for this registry key.
Problem with BrowserJavaVersion affects all releases when latest FF and Minefield are used. However, please NEVER do any dll copying to workaround the problem.
Webrev for fix is ready and we'll try to get it in to the earliest possible build of 6u5.