-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b08
-
generic
-
windows
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2214688 | 8 | Calvin Cheung | P3 | Closed | Fixed | b12 |
JDK-2216500 | 6u32 | Calvin Cheung | P2 | Closed | Fixed | b04 |
SYNOPSIS
--------
Redirection of registry keys not happening correctly with old plugin
OPERATING SYSTEM
----------------
Windows
FULL JDK VERSION
----------------
JDK 7 (tested with b147)
(Problem introduced between b138 and b143)
DESCRIPTION from LICENSEE
-------------------------
During installation, 131, 142, 150 and 160 (30 keys created for each update) are created as CAFEEFAC under HKCU (0 to 30). For example:
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBA}
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBB}
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBC}
and here we mention the key as jp2iexp.dll as default.
When we uncheck the next gen plugin in Control Panel, all of these keys should get redirected to ssv.dll, which is not happening.
A new function, RedirectSelectedStaticVersionKeysImpl(), was introduced in place of RedirectStaticVersionKeysImpl() in /deploy/src/plugin/win32/ssv_common/SSVCommonUtils.cpp. In this new function, we try to get the installed jre list and redirect only those associated CLSID's. I don't think this is right because this will lead to inconsistent behaviour as mentioned above.
I suppose the rationale behind creating all those CLSID's when the JREs aren't installed was that even if a users testcase is pointing to older CLSID it should run with latest JRE. So I don't know why we try to get the installed JREs and redirect only those keys. I'm not sure if this understanding is correct.
REPRODUCTION INSTRUCTIONS
-------------------------
1. Install JDK 7 build
2. Associate old plugin with IE
3. Launch the below applet in IE
Expected result:
It should launch with old plugin
Observed result:
It tries to launch it with old plugin, while new plugin is actually associated. I see it launches sometimes and fails sometimes.
TESTCASE
--------
jversion.html
-------------
<title>Java -version</title>
<hr>
<OBJECT classid="clsid:CAFEEFAC-0013-0001-0000-ABCDEFFEDCBA"
WIDTH = 400 HEIGHT = 30 codebase=".">
<PARAM NAME = CODE VALUE = "jversion.class" >
<PARAM NAME="type" VALUE="application/x-java-applet;jpi-version=1.3.1">
<PARAM NAME="scriptable" VALUE="false">
</OBJECT>
<hr>
jversion.java
-------------
import java.awt.*;
import java.applet.*;
public class jversion extends Applet {
public void paint(Graphics g) {
g.drawString("Java RunTime Environment is: "+System.getProperty("java.vendor")+" "+System.getProperty("java.version"), 20, 20);
}
}
--------
Redirection of registry keys not happening correctly with old plugin
OPERATING SYSTEM
----------------
Windows
FULL JDK VERSION
----------------
JDK 7 (tested with b147)
(Problem introduced between b138 and b143)
DESCRIPTION from LICENSEE
-------------------------
During installation, 131, 142, 150 and 160 (30 keys created for each update) are created as CAFEEFAC under HKCU (0 to 30). For example:
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBA}
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBB}
HKEY_CURRENT_USER\Software\Classes\CLSID{CAFEEFAC-0016-0000-0029-ABCDEFFEDCBC}
and here we mention the key as jp2iexp.dll as default.
When we uncheck the next gen plugin in Control Panel, all of these keys should get redirected to ssv.dll, which is not happening.
A new function, RedirectSelectedStaticVersionKeysImpl(), was introduced in place of RedirectStaticVersionKeysImpl() in /deploy/src/plugin/win32/ssv_common/SSVCommonUtils.cpp. In this new function, we try to get the installed jre list and redirect only those associated CLSID's. I don't think this is right because this will lead to inconsistent behaviour as mentioned above.
I suppose the rationale behind creating all those CLSID's when the JREs aren't installed was that even if a users testcase is pointing to older CLSID it should run with latest JRE. So I don't know why we try to get the installed JREs and redirect only those keys. I'm not sure if this understanding is correct.
REPRODUCTION INSTRUCTIONS
-------------------------
1. Install JDK 7 build
2. Associate old plugin with IE
3. Launch the below applet in IE
Expected result:
It should launch with old plugin
Observed result:
It tries to launch it with old plugin, while new plugin is actually associated. I see it launches sometimes and fails sometimes.
TESTCASE
--------
jversion.html
-------------
<title>Java -version</title>
<hr>
<OBJECT classid="clsid:CAFEEFAC-0013-0001-0000-ABCDEFFEDCBA"
WIDTH = 400 HEIGHT = 30 codebase=".">
<PARAM NAME = CODE VALUE = "jversion.class" >
<PARAM NAME="type" VALUE="application/x-java-applet;jpi-version=1.3.1">
<PARAM NAME="scriptable" VALUE="false">
</OBJECT>
<hr>
jversion.java
-------------
import java.awt.*;
import java.applet.*;
public class jversion extends Applet {
public void paint(Graphics g) {
g.drawString("Java RunTime Environment is: "+System.getProperty("java.vendor")+" "+System.getProperty("java.version"), 20, 20);
}
}
- backported by
-
JDK-2216500 Redirection of registry keys not happening correctly with old plugin
-
- Closed
-
-
JDK-2214688 Redirection of registry keys not happening correctly with old plugin
-
- Closed
-