JDK-6605191 : Implement modal dialog blocking of web browser
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: generic
  • Submitted: 2007-09-15
  • Updated: 2015-03-03
  • Resolved: 2007-10-31
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
6u10Resolved
Related Reports
Duplicate :  
JDK-6622332 - Initial integration of new Java Plug-In
Relates :  
JDK-6619480 - Modality-related livelock
Relates :  
JDK-6661271 - Browser hangs caused by SSV dialogs and fix for 6647406
Relates :  
JDK-8074317 - [macosx] Implement modal dialog blocking of web browser
Relates :  
JDK-6612243 - Security dialogs don't block browser
Relates :  
JDK-6681818 - Modal dialogs occasionally not working properly in new plug-in
Description
The blocking of the browser window when a Java modal dialog is active needs to be implemented, at least on the Windows platform where it is currently supported.
Comments
EVALUATION This bug is being marked as a duplicate of 6622332 for bookkeeping purposes and does not need to be re-verified independently. In the case of a regression please file a new bug.
31-10-2007
SUGGESTED FIX http://analemma.sfbay.sun.com/net/jano2/export2/hotspot/users/kbr/webrevs/mjre/6605191_modality/
18-09-2007
EVALUATION 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 Windows, including with complex round-trip Java/JavaScript modal dialog scenarios, and works well in both browsers.
18-09-2007