JDK-6612243 : Security dialogs don't block browser
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5,6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2007-10-02
  • Updated: 2011-05-13
  • Resolved: 2008-06-13
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.
JDK 6
6u10 b13Fixed
Related Reports
Duplicate :  
JDK-6661271 - Browser hangs caused by SSV dialogs and fix for 6647406
Relates :  
JDK-6605191 - Implement modal dialog blocking of web browser
Description
Modal dialogs for the security warnings about signed applets don't currently block the web browser. The reason is that these are popped up in the main AppContext and there is no associated applet for which to do the existing modality handling. It should be fairly straightforward to choose a random applet on the page to use for the purpose of blocking the browser, or it may be possible to determine on which applet's behalf the security dialog was popped up.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6612243.1 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6612243/
12-02-2008
EVALUATION Early in the development of the new plug-in, after the integration of modal dialog blocking of the browser on Windows, it was discovered that the security dialogs for signed applets don't block the browser. The reason is that these dialogs are raised in the system AppContext, and the modal dialog blocking in the new plug-in is predicated on being called in the same AppContext as the running applet. Added the ability to set a "dialog hook" in the UIFactory which is called in the applet's or application's AppContext before and after the dialog is raised. The hook allows the system to record which applet caused the dialog to be raised, so that applet can block the browser. This mechanism only works on the 1.6 JVM, because the modality hooks we use are only present in that release. However, it turns out that as far back as 1.4.2, if the owner of the dialog is specified, it will at least cause the dialog to not go behind the parent's window, though clicks on the browser window will not cause a beep and flash of the window to be performed. The dialog hook also allows an owner for the dialog to be specified through a "side channel"; this enables the use of this feature for security and other dialogs without changing large amounts of code throughout the system. Additionally, it was found that the recent fix for 6647406, which restricts the kinds of messages that are pumped during LiveConnect calls, was causing browser hangs in conjunction with the raising of the SSV dialogs, because on earlier platforms we don't receive notification from the AWT when these dialogs are raised. This issue was filed under 6661271. The hooks called before and after these dialogs are raised provide the necessary interposition points to notify the browser to modify its message pump to start processing input events while these dialogs are active. The fix for 6661271 is basically inextricable from the fix for 6612243, so with this fix, 6661271 will be closed as a duplicate of 6612243.
12-02-2008