JDK-6835274 : Nextgen plugin fails on Windows Server 2003 with multiple Administrator Users
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2003
  • CPU: x86
  • Submitted: 2009-04-28
  • Updated: 2011-02-04
  • Resolved: 2009-12-01
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.
JDK 6 JDK 7
6u16-revFixed 7Fixed
Description
The customer says this bug only appears on Windows Server 2003. It does not appear on Windows XP. However since are large customers are using Windows Server 2003, this is an important issue.

Scenario:

- Have an applet which is referenced using the OBJECT tag and using a family classid (clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA).

- Have a Windows Server 2003 client system with only Java 5.0 update 17 installed

- Have 2 users (both with administrator privileges) defined on the Windows Server 2003 system.

- For both users, the applet is started correctly when opening the html page.

- One of the 2 users installs Java 6.0 update 12.

- The administrator who performed the Java 6.0 installation can open the html page and the applet is started correctly.

- Login with the other administrator. When accessing the html page, the Java Plug-in is not started (red cross is shown).

- Disable the next generation Plug-in in the control panel. Now, the applet can be started correctly.

- Enable the next generation plug-in in the control panel (so revert to the original settings). Strangely, now the applet is started succesfully. This workaround however cannot be applied to our customers as users often cannot change the settings in the control panel.

This bug can be reproduced always. Note also that when using a specific java update version in the classid, the problem doesn't occur.

This issue no longer fails once the "enable third party extensions" option is turned on under Internet Explorer. The change we made is to the Internet Explorer options. From the IE Tools menu, select Internet Options and then the Advanced tab. Under the Browsing section, make sure "Enable third party browser extensions (requires restart)" is turned on. You need to restart IE to make the change effective.

Customer reported this is not viable solution for him for the following reasons:

1. When only Java 5.0 is installed, the applet starts up correctly (with the family classid for Java 5.0) even if "Enable third party browser extensions" is turned off. After installing Java 6.0, the applet doesn't start anymore. Why does the installation of Java 6.0 require the new setting? As it works with Java 5.0, the installation of Java 6.0 breaks a working environment.

2. The user who has installed Java 6.0 can perfectly run the Java applet (with the family classid for Java 5.0) even if the "Enable third party browser extensions" is turned off. During the whole scenario, this setting was not turned on for this user. Why is the setting required for one user and not for the other?

3. As mentioned in the original description of the problem, the applet starts correctly after having disabled the next generation plug-in and re-enabling it. This proves that the Internet Explorer setting "Enable third party browser extensions" is not required after all.

4. After having turned on "Enable third party browser extensions" as you suggested, the applet starts-up correctly. Then, after turning off "Enable third party browser extensions", the applet still starts up correctly. This confirms again that the applet can start without this Internet Explorer setting. It looks as if some initial configuration needs to be completed first.

Considering all the above, is it possible to have a fix in Java 6.0 which allows the usage of family classids for all Windows user without the need for a manual configuration change, just as it used to be in Java 5.0?

Having to change the configuration is not a valid workaround as it needs to be done for all Windows Users. Windows 2003 is often used as a terminal Server, where the users do not have access to these configuration settings, and often they cannot be changed because of security restrictions.
Comments
EVALUATION Cause: windows server 2003 is a server machine and is designed to be more secure and therefore has disabled some features in the IE browser including the disabling of third party extension such as Browser Helper Object. Since BHO has been disabled, our ssv module won't get invoked when the IE browser starts. It works for the user who installes the JRE 6.0 update release because the installer sets the redirect registry key under the HKCU branch for that only that user. However, the family clsid key under the HKLM branch wasn't set correctly. Fix: during installation, instead of always pointing the family clsid registry key to ssv.dll, we need to check if the new plugin is enabled by reading a registry key and setting the name of the dll accordingly.
26-06-2009
EVALUATION The plugin2 (new/nextgen plugin) install sets some registry keys for the user installing the product. This is why the user who does the install can run the applets without enabling third party extensions. Toggling between the old and new java plugin has the effect of setting up some registry keys which is similar to enabling third party browser extensions. Once this is done and/or "Enable third party browser extensions" has been turned on, the registry keys will be set and they'll remain set even after the third party extensions has been disabled.
28-04-2009