United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6929996 Request for method to disable the next gen plugin for end user managed account on Windows
JDK-6929996 : Request for method to disable the next gen plugin for end user managed account on Windows

Details
Type:
Enhancement
Submit Date:
2010-02-25
Status:
Closed
Updated Date:
2011-12-03
Project Name:
JDK
Resolved Date:
2011-10-18
Component:
deploy
OS:
windows_vista,windows
Sub-Component:
plugin
CPU:
generic
Priority:
P1
Resolution:
Fixed
Affected Versions:
6u18,6u20
Fixed Versions:
6u30 (b08)

Related Reports
Backport:
Relates:

Sub Tasks

Description
Customer would like to disable the next gen plug-in remotely for thousands of PCs and they say that this works when they do this via the Java Control Panel but fails when they try to do this through modification of a registry key.  The problem is seen both with Windows XP as well as Windows Vista.  It appears the customer has a legacy application which they need to also run on these systems using 5.0u22 and the application does not function properly when the next gen plug-in is enabled.  

They specify to load their legacy application using family clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA.

The customer has managed desktops, with user that have restricted policies that would
prevent them access to the Java Control Panel so customer must implement the setting change for them remotely during, nightly maintenance window. 

Since the next gen plugin can be disabled in the Java Control Panel, there should also be a supported way to disable it via installation, registry or other method for multiple managed user desktop accounts.

Please see comments section and attachments for the test results from the customer.

                                    

Comments
SUGGESTED FIX

There is a way to switch between old/new Java plugin from a command line.
I tested it on jre 6u19 on windowsXP so far:

Log in as an admin user.
goto <jre_installation_directory>\bin

In order to switch from new to old plugin:
run ssvagent.exe -high -jpisetup -old

In order to switch from old to new plugin:
run ssvagent.exe -high -jpisetup -new
                                     
2010-04-28
SUGGESTED FIX

ssvagent.exe -high -jpisetup -new does the registry change:
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.6.0_18]
  "UseNewJavaPlugin"=dword:00000000
which affects all users (accounts) registered on a machine.
The rest of necessary registry changes ssvagent.exe does for a current user only.
When a new user logs in the necessary registry modification get propagated to that user on IE startup by ssv.dll.
The problem was that since jre6u12 IE doesn't load ssv.dll on a startup (see CR #6953625).
So that's why ssvagent.exe didn't work correctly for a customer in a multiuser environment.      

As a workaround we gave the customer a set of registry to manually propagate to all users:

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\1.6.0_18]
"UseNewJavaPlugin"=dword:00000000

[HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA}\InprocServer32]
@="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll"
"ThreadingModel"="Apartment"

[HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-0022-ABCDEFFEDCBA}\InprocServer32]
@="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll"
"ThreadingModel"="Apartment"

[HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-0022-ABCDEFFEDCBB}\InprocServer32]
@="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll"
"ThreadingModel"="Apartment"

[HKEY_CURRENT_USER\Software\Classes\CLSID\{CAFEEFAC-0015-0000-0022-ABCDEFFEDCBC}\InprocServer32]
@="C:\\Program Files\\Java\\jre6\\bin\\ssv.dll"
"ThreadingModel"="Apartment"

Note:
Assume JRE 6 update release is installed in a regular location
C:\\Program Files\\Java\\jre6

Above registry changes will make a Java applet which is requesting jre 5u22
to use also Java Plugin 5u22 (which is an old plugin).


When CR #6953625 get fixed then
ssvagent.exe -high -jpisetup -old
will work correctly even in a multiuser environment without a need for manual registry modification as described above.
                                     
2010-05-18
EVALUATION

See Suggested Fix section.
                                     
2010-05-18
SUGGESTED FIX

.
                                     
2010-12-08
WORK AROUND

Attached is SSVHelper.cmd which customer needs to run from a command line
after an installation process of JRE6 is completed. This script registers
Browser Helper Objects called SSVHelper with IE. This object is responsible
for a propagation of Java Plug-in settings from admin account to all regular
(non admin) user accounts.
In other words if SSVHelper is registered with IE
then the only thing admin needs to do in order to switch from a new Java Plug-in to an old Java Plug-in is to run from a command line:

ssvagent.exe -high -jpisetup -old
 
or uncheck a checkbox "Enable the next generation Java Plug-n" in Java Control Panel.
In both cases changes will be propagated to non admin user accounts.

NOTE:
SSVHelper.cmd  needs to be executed only once after JRE6 installation is completed.
All subsequent switching between new/old Java Plug-in do not require
SSVHelper.cmd to be executed any more.

To manually register SSVHelper object
run SSVHelper.cmd when jre installation is completed.
usage: SSVHelper.cmd [JRE_HOME_DIRECTORY]
JRE_HOME_DIRECTORY is optional. If not specified then
a default location of jre6 is assumed which is
"C:\Program Files\Java\jre6"

Example 1 (JRE installed in a default location):
jre-6u22-windows-i586.exe
SSVHelper.cmd

Example 2 (JRE installed in a custom location):
jre-6u22-windows-i586.exe /s INSTALLDIR=C:\myJava\jre
SSVHelper.cmd C:\myJava\jre
                                     
2010-12-08
SUGGESTED FIX

Incorrect registration of Browser Helper Objects called SSVHelper with IE (CR #6953625) has been fixed:

http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3896

SSVHelper object is responsible
for a propagation of Java Plug-in settings from admin account to all regular
(non admin) user accounts.
If SSVHelper is registered with IE
then the only thing admin needs to do in order to switch from a new Java Plug-in to an old Java Plug-in is to run from a command line:

ssvagent.exe -high -jpisetup -old
 
or uncheck a checkbox "Enable the next generation Java Plug-n" in Java Control Panel.
In both cases changes will be propagated to non admin user accounts.
                                     
2011-01-07
SUGGESTED FIX

Test case:
step 1: install any jre5 (for example 5u22)
step 2: install jre6 containing a fix.
step 3: as an administrator switch to an old Java plug-in running from a command line:

ssvagent.exe -high -jpisetup -old

or just simply uncheck a checkbox "Enable the next generation Java Plug-n" in Java Control Panel.

step 4: log out from an admin account and log in as a regular (non admion) user
step5: run (as a regular user) Java any applet using

clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA

as mentioned in "Description section" above

Step 6:
Verify if JavaConsole reports 5u22 for both JavaPlugin and JRE like below:
Java Plug-in 1.5.0_22
Using JRE version 1.5.0_22 Java HotSpot(TM) Client VM

before fix  new Java plug-in of jre6 was still active so Java Console output was:
Java Plug-in 1.6.0_18
Using JRE version 1.5.0_22-b03 Java HotSpot(TM) Client VM

See attached customer files:
app with plugin2 turned off (via reg change) Error.rtf
app with plugin2 turned off(manually via JCP) success.rtf
app with plugin2engaged (default) Error.rtf
                                     
2011-01-12



Hardware and Software, Engineered to Work Together