JDK-8088395 : Print dialogs are not blocking/modal w.r.t specified owner windows
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-01-28
  • Updated: 2020-01-31
  • Resolved: 2017-03-15
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.
8u152Fixed 9Fixed
Related Reports
Blocks :  
Duplicate :  
Relates :  
Relates :  
Relates :  
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.
+1 Approved to push to 8u-dev for 8u152.

Please approve an 8u backport of this fix webrev: http://cr.openjdk.java.net/~prr/8088395.8u/

changeset: 10380:a7e9f63e172a tag: tip user: prr 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... +1

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/

9-critical-watch: 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(); s.initOwner(w); s.initStyle(StageStyle.TRANSPARENT); s.setX(0); s.setY(0); s.setWidth(1); s.setHeight(1); s.initModality(Modality.WINDOW_MODAL); s.show(); boolean ok = job.showPrintDialog(w); s.hide(); === 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: J2DPrinterJob::showPrintDialogWithNestedLoop(Window owner) 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.