JDK-6699106 : Applets requesting insecure version of JRE fails to load if Cancel is pressed
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_vista
  • CPU: generic,x86
  • Submitted: 2008-05-08
  • Updated: 2011-02-16
  • Resolved: 2008-06-16
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.
6u10 b26Fixed
Related Reports
Duplicate :  
Duplicate :  
As per specs against newly introduced multi JRE support, security Warning pop-up is going to be there while loading applets requesting insecure versions of JRE e.g. 1.5.0_10,which behaves as follows:
1) Click "Run" on the security pop-up and applets will get loaded using requested but insecure version of JRE
2) Click "Cancel" on the security pop-up and applets will get loaded using secure and latest version of JRE i.e. 6u10 or later

While #1 works fine but it has been noticed that #2 is not working as per specs. Following has been noticed when Cancel is pressed:
- Applets are not getting loaded using 6u10
- It has been noticed that some extra security warning pop-ups are coming up e.g. if page contains 2 applets requesting for insecure version , then 
   - if User clicks on "Run" then no. of security dialogs are 2
   - If User clicks on "Cancel" then no. of security pop-ups are more than 2

Steps to reproduce:
 Install JRE 1.5.0_10 and 6u10-b23 and then load the following testcase which has 2 applets requesting for java_version 1.5.0_10.
2)Click on "Run" button on the security warning pop-ups 
   - Applets should get loaded using 1.5.0_10
   - Make sure that no. of pops are equal to 2
3) CLose the browser and run the same applets again .
4)Click on "Cancel" button on the security warning pop-ups 
   - If applets fails to load using 6u10 then bug is reproduced
   - If this time no. of pop-ups are more than 2 then other issue mentioned above is reproduced

Applet are getting loaded fine when "cancel" is pressed using 6u10-b14 but failing for 6u10-b22 and 6u10-b23

SUGGESTED FIX Fixing support for the OOPP/JNLP use case: - Selecting an insecure non SSV JRE in the JNLP file - User does not allow this JRE, ie press Cancel in the SSV dialog - Run the applet with the latest default JRE Fixing SSV canceled relaunch for applets. - setting start applet parameters - fireAppletIsUnsigned() -> fireAppletSSVValidation() - appletIsUnsigned() -> appletSSVValidation() - PluginMain.appletSSVValidation() no more relaunches directly, just returns the result. Plugin2Manager: - In case of a canceled SSV UI dialog, we exit createApplet() with a JRESelectionException. - The 'catch JRESelectionException' case already takes care of a proper exit and relaunch. Note: Dropping the idea of an SSV relaunch optimization in case of JNLP in favor to a simpler fix and deterministic JRE relaunch version. +++ testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6699106/ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6699106.3/ workspace: j2se engineer: sven.gothel

EVALUATION Instead of abortion, the Plugin2Manager (etc) shall continue to relaunch with the latest JVM. The StartApplet technique can be used here.

EVALUATION There're 2 problems in this report: 1) applets failed to load - relauching of applets with the latest JRE failed. 2) the number of security dialogs is more than the number of applets Problems #1 is due to NPE in the server side: java.lang.NullPointerException JRE Pipe.cstr: WindowsNamedPipe: server: false; readPipe: jpi2_pid1956 _pipe5, readBufferSz: 4096; writePipe: jpi2_pid1956_pipe6, writeBufferSz: 4096 at sun.plugin2.main.server.JVMInstance.startApplet(JVMInstance.java:295) at sun.plugin2.main.server.JVMManager.startAppletImpl(JVMManager.java:244) at sun.plugin2.main.server.JVMManager.relaunchApplet(JVMManager.java:167) at sun.plugin2.main.server.JVMInstance$WorkerThread.run(JVMInstance.java:914) The NPE is due to the Plugin object in JVMInstance.startApplet is null; the plugin.getDocumentBase() results in NPE. The JVMInstance calls unregisterApplet() which removes the plugin object from the appletToPluginMap in response to the StartAppletResultMessage with status set to APPLET_ABORTED. The cause is due to Plugin2Manager calls setErrorOccurred() under the situation when the user selects "Cancel" on launching the applet using an insecure JVM. The setErrorOccurred() sets a boolean flag and eventually triggers the call to fireAppletErrorOccurred() which sends the mentioned StartAppletResultMessage to the server side. At this point, it is unclear is the 2 problems are related. If they aren't related, a separate CR will be opened for problem #2.