JDK-8101938 : Provide an option to allow modal windows to be blocking
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-02-21
  • Updated: 2015-06-16
  • Resolved: 2012-04-16
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 7
7u6Fixed
Related Reports
Duplicate :  
JDK-8102068 - request: show() of modal dialog that blocks waiting for dialog to be closed
Relates :  
JDK-8097791 - Add javafx.scene.control.Alert class
Description
Opening a modal window does not currently block execution of the calling code while the window is open. See attached test case - the label in the modal window reads "I am not blocking!" rather than "I am blocking!". This is different from the behavior of ShowDialog() on Windows or runModalForWindow: on the Mac, which prevent the opening window from processing events until the modal window is closed.
Comments
Verified by SQE with FX2.2 b16.
10-07-2012
Testing done. Test: SceneGraphTests/test/test/scenegraph/modality/ShowAndWaitTest.java (http://shaman.russia.sun.com/hg/index.cgi/java-client/file/f8810a4f9ef4/SceneGraphTests/test/test/scenegraph/modality/ShowAndWaitTest.java)
31-05-2012
Unit Tests: javafx/stage/ShowAndWaitTest
16-04-2012
http://jfxsrc.us.oracle.com/javafx/2.2/scrum/graphics/apps/rev/3d2e0eb29fe2 http://jfxsrc.us.oracle.com/javafx/2.2/scrum/graphics/deploy/rev/5343884da3f1 http://jfxsrc.us.oracle.com/javafx/2.2/scrum/graphics/rt-closed/rev/7f575f074f4d http://jfxsrc.us.oracle.com/javafx/2.2/scrum/graphics/rt/rev/eb8eb40f9746 http://jfxsrc.us.oracle.com/javafx/2.2/scrum/graphics/webnode/rev/b63c1f17f8d5
16-04-2012
SQE: 1 day of work
11-04-2012
Proposed new API: Stage class: /** * Show the stage and wait for it to be closed before returning to the * caller. This must be called on the FX Application thread. The stage * must not already be visible prior to calling this method. This must not * be called on the primary stage. * * @throws IllegalStateException if this method is called on a thread * other than the JavaFX Application Thread. * @throws IllegalStateException if this method is called on the * primary stage. * @throws IllegalStateException if this stage is already showing. */ public void showAndWait(); Note that this method is already implemented as the internal "@treatAsPrivate" method impl_showAndWait() so it well-tested. Additionally I am writing new unit tests.
10-04-2012
Given the time estimate for dev (about 3 or 4 days) and SQE (2 days), I am changing this simple feature request to a Tweak.
29-03-2012
SQE / OK 2 days of test development
27-03-2012
To comment on the specific points: - The functionality is planned for the Stage class. - The description of the control flow is exactly what impl_showAndWait() does today. - Ignoring keystrokes, mouse clicks and gestures for other windows is controlled by the existing modality attribute, set by calling initModality() Note that you could experiment today with this functionality by calling impl_showAndWait() on a modal dialog and see if that meets your needs since the most likely implementation of this will be to remove the "@treatasprivate" and "@Deprecated" tags, and strip the impl_ prefix from the name. I believe that it functionally does what is needed already.
19-03-2012
We will do this in 2.2.
19-03-2012
The following more succinctly describes what is needed. . the dialog must to be a Stage so that arbitrary controls can be placed on it . the method name doesn't matter, showAndWait() would be fine . the method waits until the dialog is hidden by the programmer calling hide() in an event handler method, at which time execution continues at the statement after the showAndWait() . keystrokes, mouse clicks and gestures are ignored and discarded for other windows Is this functionality that is being considered? If so, for which release? Again thanks for any information you can provide. We've got to decide whether or not to plan on supporting JavaFX this year.
19-03-2012
So I added a new feature request (20451) after seeing the comment by Kevin "A modal dialog is not supposed to block ... This is by design." Quite simply, this "design" is unacceptable to us. Please change the design. And FWIW, we need more than an "Alert". We need to be able to do things like ask for name and password, etc. The File Chooser built-in dialog is a prime example. We need to provide other such choosers for all sorts of objects and things, not just files. Please advise if and when a blocking modal show() will be implemented. TIA.
19-03-2012
Yes, Graphics is a good place for this issue. The needed functionality is already in place in Quantum and is used by the impl_ @treatasprivate method impl_showAndWait() method on Stage. Fulfilling this request may be as simple as making the impl_showAndWait() part of the public API (removing impl_ from the name, of course).
22-02-2012
I'm removing the Glass component because Glass provides complete support for implementing execution-blocking behavior. A Glass client can block the execution on the event thread by starting a nested event loop to process events for a modal window (actually, for all non-blocked windows). The Window.setEnabled() API allows to block/unblock windows individually. These features together allow a Glass client to implement any kind of modality they may desire. For now I'm re-dispatching this issue to Graphics component since Quantum may need to provide additional support for these Glass features.
22-02-2012
What I mean by "blocking events" is that the run loop should shift from the main window to the modal window while the modal window is open, and only return to the main window when it is closed. This request differs from RT-12643 in that Alert is generally a stock window type with limited options for customization (e.g. JOptionPane, Windows MessageBox, Mac NSAlert) whereas this feature would be supported by an arbitrary window/stage.
21-02-2012
If you really want to make this a feature request then you might want to file a new issue as the description talks about both blocking the execution (which you are correct in that we don't do), but also talks about preventing events from being processed which is already implemented and working correctly. Also, you may want to describe how your request differs from RT-12643.
21-02-2012
A modal dialog in JavaFX is not supposed to block the execution thread. This is by design. See HelloModality for an example of how modal dialogs work. We don't have a mechanism using public API to block the execution. There is private API to do this, impl_showAndWait() but it is not supported. There is also a feature request -- RT-12643 -- to add an Alert class that is blocking. See HelloAlert for a prototype of how this might work.
21-02-2012