JDK-6605191 : Implement modal dialog blocking of web browser
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.
Implemented blocking of the web browser when a Java modal dialog is
active. Currently this is only supported on Windows, though if
investigation is done into how to run a subordinate Xt message loop,
it could potentially be enabled on X11 platforms as well.
The underlying mechanism is similar to that used by the in-process
plugin. When a modal dialog is up, we install hook procedures on the
browser's main thread which both filter out certain kinds of events as
well as re-activate the Java modal dialog when necessary.
Detection of modality changes is performed by the client process (that
executing the applet). On Java SE 6, where the sun.awt.ModalityListener
interface is supported, that will be used to detect modality changes.
Otherwise, a subclass of WEmbeddedFrame / XEmbeddedFrame will be
created to hold the applet and notifyModalBlocked() overridden.
When a modal dialog is raised or dismissed, a message is sent to the
browser over the new plugin's messaging system, which causes the
Windows hook procedures to be installed or removed on the plugin's
main thread. No changes were necessary to the existing subordinate
message pumps used by LiveConnect and other subsystems. Safety
mechanisms have been put in place (in platform- and browser-
independent code) to guard against browser lockups in case of an event
like a JVM crash. These mechanisms have been tested.
The new implementation has been tested with IE 7 and Firefox 3 on
dialog scenarios, and works well in both browsers.