RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

Phil Race
This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

prasanta sadhukhan

Looks ok to me.

Regards
Prasanta
On 3/11/2017 3:56 AM, Phil Race wrote:
This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

Sergey Bylokhov
In reply to this post by Phil Race
Hi, Phil.
I have only two questions:
 - Does it mean that we do not support "ontop" property via public API in idk?
 - Probably the name should contain «owner» instead of «parent»?, But since this is not a public API I guess it is not an issue.



This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.

Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

Phil Race
I have updated webrevs described below, and also I answer your questions

FX is updated only to fix trailing white space and one modifier ordering
http://cr.openjdk.java.net/~prr/8088395.1/

The JDK side has a few modifications :
http://cr.openjdk.java.net/~prr/8176350.1/
(a) awt_PrintDialog.cpp and awt_PrintJob.cpp have an added safety check.
We now call ::IsWindowHandle(id) as we do elsewhere to make sure its valid.

(b) The Page Setup Dialog on Linux was not seeing the AlwaysOnTop property.
In part this was because it wasn't being checked in ServiceDialog.initPageDialog() - fixed
In other part it is because the attributes weren't propagated. The reason for this is
a bit lengthy to explain but the main thing to say is that we have an instance variable
attributes as well as a local variable in some places.
I didn't want to touch any code that even theoretically might affect 2D printing so
instead I cached the attribute as we do the owner id so it is passed on properly
Thanks to Kevin for spotting this problem


On 03/14/2017 09:02 AM, Sergey Bylokhov wrote:
Hi, Phil.
I have only two questions:
 - Does it mean that we do not support "ontop" property via public API in idk?

There is no API for the "alwaysOnTop" AWT property for the print dialogs.
I actually don't think it can be implemented for the windows native print controls.
There is an internal way to make an AWT window owner for the Swing print dialog
but nothing public and it doesn't help here as the owner is not an AWT window.


 - Probably the name should contain «owner» instead of «parent»?, But since this is not a public API I guess it is not an issue.

I suppose that is more correct. Something to address if it ever makes its way into API or docs.

-phil.




This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.


Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

Kevin Rushforth
Changes look good to me. All testing is fine, too.

+1 for both halves of the fix

-- Kevin


Phil Race wrote:

> I have updated webrevs described below, and also I answer your questions
>
> FX is updated only to fix trailing white space and one modifier ordering
> http://cr.openjdk.java.net/~prr/8088395.1/
>
> The JDK side has a few modifications :
> http://cr.openjdk.java.net/~prr/8176350.1/
> (a) awt_PrintDialog.cpp and awt_PrintJob.cpp have an added safety check.
> We now call ::IsWindowHandle(id) as we do elsewhere to make sure its
> valid.
>
> (b) The Page Setup Dialog on Linux was not seeing the AlwaysOnTop
> property.
> In part this was because it wasn't being checked in
> ServiceDialog.initPageDialog() - fixed
> In other part it is because the attributes weren't propagated. The
> reason for this is
> a bit lengthy to explain but the main thing to say is that we have an
> instance variable
> attributes as well as a local variable in some places.
> I didn't want to touch any code that even theoretically might affect
> 2D printing so
> instead I cached the attribute as we do the owner id so it is passed
> on properly
> Thanks to Kevin for spotting this problem
>
>
> On 03/14/2017 09:02 AM, Sergey Bylokhov wrote:
>> Hi, Phil.
>> I have only two questions:
>>  - Does it mean that we do not support "ontop" property via public
>> API in idk?
>
> There is no API for the "alwaysOnTop" AWT property for the print dialogs.
> I actually don't think it can be implemented for the windows native
> print controls.
> There is an internal way to make an AWT window owner for the Swing
> print dialog
> but nothing public and it doesn't help here as the owner is not an AWT
> window.
>
>
>>  - Probably the name should contain «owner» instead of «parent»?, But
>> since this is not a public API I guess it is not an issue.
>
> I suppose that is more correct. Something to address if it ever makes
> its way into API or docs.
>
> -phil.
>
>>
>>>
>>>
>>> This has an FX bug + webrev :
>>> https://bugs.openjdk.java.net/browse/JDK-8088395
>>> http://cr.openjdk.java.net/~prr/8088395/index.html 
>>> <http://cr.openjdk.java.net/%7Eprr/8088395/index.html>
>>>
>>> and also a JDK-side fix and webrev :-
>>> https://bugs.openjdk.java.net/browse/JDK-8176530
>>> http://cr.openjdk.java.net/~prr/8176350/
>>>
>>> The problem is FX modal dialogs are ignoring the Window parameter.
>>> We can fix the problem with disabling the modal parent on the FX side
>>> and that is why most files in FX are updated.
>>>
>>> But it does not fix the "on top" issue which requires the JDK fixes and
>>> to pass in the DialogOnTop private attribute.
>>> The JDK code is there solely for FX and won't have any visibility
>>> unless FX passes in the private attribute.
>>>
>>> On Linux it uses the standard AWT "always on top" modality
>>> On windows it uses the HWND for the FX window and windows native
>>> modality
>>> On Mac you won't see anything since Mac does this automatically
>>>
>>> -phil.
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

Sergey Bylokhov
In reply to this post by Phil Race

There is no API for the "alwaysOnTop" AWT property for the print dialogs.
I actually don't think it can be implemented for the windows native print controls.
There is an internal way to make an AWT window owner for the Swing print dialog
but nothing public and it doesn't help here as the owner is not an AWT window.

Ok.



 - Probably the name should contain «owner» instead of «parent»?, But since this is not a public API I guess it is not an issue.

I suppose that is more correct. Something to address if it ever makes its way into API or docs.

-phil.




This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.



Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8088395: Print dialogs are not blocking/modal w.r.t specified owner windows

prasanta sadhukhan
In reply to this post by Phil Race

Looks good to me.

Regards
Prasanta
On 3/14/2017 11:02 PM, Phil Race wrote:
I have updated webrevs described below, and also I answer your questions

FX is updated only to fix trailing white space and one modifier ordering
http://cr.openjdk.java.net/~prr/8088395.1/

The JDK side has a few modifications :
http://cr.openjdk.java.net/~prr/8176350.1/
(a) awt_PrintDialog.cpp and awt_PrintJob.cpp have an added safety check.
We now call ::IsWindowHandle(id) as we do elsewhere to make sure its valid.

(b) The Page Setup Dialog on Linux was not seeing the AlwaysOnTop property.
In part this was because it wasn't being checked in ServiceDialog.initPageDialog() - fixed
In other part it is because the attributes weren't propagated. The reason for this is
a bit lengthy to explain but the main thing to say is that we have an instance variable
attributes as well as a local variable in some places.
I didn't want to touch any code that even theoretically might affect 2D printing so
instead I cached the attribute as we do the owner id so it is passed on properly
Thanks to Kevin for spotting this problem


On 03/14/2017 09:02 AM, Sergey Bylokhov wrote:
Hi, Phil.
I have only two questions:
 - Does it mean that we do not support "ontop" property via public API in idk?

There is no API for the "alwaysOnTop" AWT property for the print dialogs.
I actually don't think it can be implemented for the windows native print controls.
There is an internal way to make an AWT window owner for the Swing print dialog
but nothing public and it doesn't help here as the owner is not an AWT window.


 - Probably the name should contain «owner» instead of «parent»?, But since this is not a public API I guess it is not an issue.

I suppose that is more correct. Something to address if it ever makes its way into API or docs.

-phil.




This has an FX bug + webrev :
https://bugs.openjdk.java.net/browse/JDK-8088395
http://cr.openjdk.java.net/~prr/8088395/index.html

and also a JDK-side fix and webrev :-
https://bugs.openjdk.java.net/browse/JDK-8176530
http://cr.openjdk.java.net/~prr/8176350/

The problem is FX modal dialogs are ignoring the Window parameter.
We can fix the problem with disabling the modal parent on the FX side
and that is why most files in FX are updated.

But it does not fix the "on top" issue which requires the JDK fixes and
to pass in the DialogOnTop private attribute.
The JDK code is there solely for FX and won't have any visibility
unless FX passes in the private attribute.

On Linux it uses the standard AWT "always on top" modality
On windows it uses the HWND for the FX window and windows native modality
On Mac you won't see anything since Mac does this automatically

-phil.