JDK-8088395 : Print dialogs are not blocking/modal w.r.t specified owner windows
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.
The PrinterJob.showPrintDialog and showPageSetupDialog methods take a Window parameter.
This is supposed to specify the owner window which is blocked whilst the dialog is displayed.
Currently the owner is ignored.
Approved to push to 8u-dev for 8u152.
Please approve an 8u backport of this fix
date: Wed Mar 15 11:22:45 2017 -0700
summary: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows
Already replied on the list...
Updated webrev is here: http://cr.openjdk.java.net/~prr/8088395.1/
Tested on Windows, Mac, Linux. Windows and Mac work fine. On Linux the Modal Print Dialog is fine, but the Modal Print Setup is not always on top.
FX side of code changes looks fine. Two formatting comments:
1. Be sure to run 'hg jcheck' as 3 of the files have trailing whitespace
2. Minor nit:
+ static private Class onTopClass = null;
Usually we put private before static (up to you whether to change this).
FX fix here: http://cr.openjdk.java.net/~prr/8088395/index.html
JDK bug : https://bugs.openjdk.java.net/browse/JDK-8176530
JDK part of the fix here : http://cr.openjdk.java.net/~prr/8176350/
This is P2 blocker issue. The owner window is blocked whilst the dialog is displayed
Importance: High : CAP bug,
The following code in the user application can be used to faily effectively synthesise one of the
required behaviours : ie that the original window be "blocked" whilst the print dialog is up
Window w = btn.getScene().getWindow();
Stage s = new Stage();
boolean ok = job.showPrintDialog(w);
This displays an invisible undecorated minimal size top-level window for the duration of the time the dialog is shown.
It effectively blocks all input to the "parent" window by making the invisible window a modal child.
Something that doesn't need such an invisible window but calls into the same internal mechanisms can be used to
implement this part of the actual fix, purely on the FX side, but in the meantime this is an effective application-level workaround.
The other part of the problem - making sure the dialog stays on top of rhe owner window so far seems like it will require
per-platform solutions that touch 2D as well as FX.
3/8/2017: This bug is still on investigation phase to prepare the fix
Still pending a fix for customer as high priority issue. Targeted to 9.
Note that there are really two separate issues here. First, the dialog isn't a child window of the FX window, meaning that it isn't necessarily kept on top of the FX window. Second, it isn't modal, and as such doesn't block events from going to the FX window.
The owner parameter is unused in the following implementation method:
In order to implement this, we need a way for a Swing/AWT window to be owned by (a child of) an FX window.
A critical issue for the CAP member and would like it be fixed in 8u update release if possible.
Same issue reported by a CAP member and would like it be fixed in JDK 8 update releases -
As we are moving forward with a JavaFX conversion of our application, I am curious why JDK-8088395 has been dropped to P4. It has a classification of ���nicetohave,��� however not having this work correctly really complicates the code of anything that wants to use these dialogs. I would not consider this a convenience feature.
It is possible to hit the ���Print��� button several times and it brings up the native print dialog each time, check the test problem. It is not difficult to have 20 or so dialogs open at once, although errors start occurring at this point.
Opening up multiple dialogs is not the expected behavior. It can also be dangerous, as a user could accidently bring up more than one dialog, print from one and go on their way. Later, they may find that old dialog and click ���OK���. Who knows what that would do? The state that was around when that dialog was created may not be valid anymore.
Since the dialog is not tied to the owner, having stray print dialogs seem pretty likely. Consider the scenario where a user bring up that dialog, but then click on another window. A user would expect that the clicking back on the source window would reveal the print dialog. However, in the current implementation, it will not. A user may well assume that the dialog just canceled itself, and bring up this print dialog again. However, the original print dialog would still be around, and probably would not be noticed unless a user looked on the task bar.
Please consider fixing this in Java 8 as working around this issue complicates developer code and really can���t provide the proper user experience.
We have a pretty annoying problem related to this issue. Currently the print dialog is opened "behind" our full screen application and will stay unnoticed until the application is minimized.
Clarification: this is only an issue when running the application through Webstart
The impact of the bug doesn't seem high, so lowering to P4.