United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6612243 Security dialogs don't block browser
JDK-6612243 : Security dialogs don't block browser

Details
Type:
Bug
Submit Date:
2007-10-02
Status:
Closed
Updated Date:
2011-05-13
Project Name:
JDK
Resolved Date:
2008-06-13
Component:
deploy
OS:
windows
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u5,6u10
Fixed Versions:
6u10 (b13)

Related Reports
Duplicate:
Relates:

Sub Tasks

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/
                                     
2008-02-12
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.
                                     
2008-02-12



Hardware and Software, Engineered to Work Together