United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6699106 Applets requesting insecure version of JRE fails to load if Cancel is pressed
JDK-6699106 : Applets requesting insecure version of JRE fails to load if Cancel is pressed

Details
Type:
Bug
Submit Date:
2008-05-08
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2008-06-16
Component:
deploy
OS:
windows_vista,generic
Sub-Component:
plugin
CPU:
x86,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b26)

Related Reports
Duplicate:
Duplicate:

Sub Tasks

Description
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:
--------------------
1) 
 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.
http://sqeweb.sfbay.sun.com/deployment2/jitu/deployment_mustang_exec_ws/deployment/src/plugin/MultiJRE/MultiJRE/html/Specific150_10Test.html
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

                                    

Comments
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 1.6.0.10: 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.
                                     
2008-05-13
EVALUATION

Instead of abortion, the Plugin2Manager (etc) shall continue to relaunch with the latest  JVM. The StartApplet technique can be used here.
                                     
2008-05-14
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
                                     
2008-05-21



Hardware and Software, Engineered to Work Together