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.
|
Java