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:
JRE 22.214.171.124: Pipe.cstr: WindowsNamedPipe: server: false; readPipe: jpi2_pid1956
_pipe5, readBufferSz: 4096; writePipe: jpi2_pid1956_pipe6, writeBufferSz: 4096
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.
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.
- 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.