<AWT Dev> <AWT dev>[10] Review request for JDK-8190767: [macos] if JFrame is maximized on OS X, all new JFrames will be maximized by default

Phil Race philip.race at oracle.com
Tue Feb 20 20:20:44 UTC 2018


I suspect Sergey looked at the UDIFF which is cut off such that it does not
show the important line that does appear in the SDIFF

  679             if (target instanceof Frame)

-phil.

On 02/20/2018 12:16 PM, Kevin Rushforth wrote:
> I can't speak to whether the logic is correct or not. I was just 
> pointing out that the cast on line 692 is safe; since it is in an "if 
> (target instanceof Frame)" block, "target" is already known to be a 
> Frame.
>
> -- Kevin
>
>
> Sergey Bylokhov wrote:
>> On 20/02/2018 11:35, Kevin Rushforth wrote:
>>> The new code is already inside an "if (target instanceof Frame)" 
>>> check...
>>
>> But the Frame is not a Dialog. The code which were removed in the fix 
>> was executed under this checks:
>> // Either java.awt.Frame or java.awt.Dialog can be resizable
>> resizable = isFrame ? ((Frame)target).isResizable() : (isDialog ? 
>> ((Dialog)target).isResizable() : false);
>>
>>>
>>> -- Kevin
>>>
>>>
>>> Sergey Bylokhov wrote:
>>>> Hi, Manajit.
>>>> You cannot cast the target to a Frame without any checks, because 
>>>> it is not necessary a Frame.
>>>>
>>>> On 16/02/2018 03:48, Manajit Halder wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Please review the modified fix. The current webrev maintains the 
>>>>> window behaviour after it is shown as per the current implementation.
>>>>> canFullScreen is set true in case the window is resizable.
>>>>>
>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.02/
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>>
>>>>>> On 14-Feb-2018, at 8:29 AM, Sergey Bylokhov 
>>>>>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi, Manajit.>http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/
>>>>>> After the window is shown behavior should be the same as in 
>>>>>> current implementation(resizable windows should have 
>>>>>> canFullScreen=true, others canFullScreen=false) so you cannot 
>>>>>> just set it to "true" or "false".
>>>>>>
>>>>>>> The issue is not reproducible in jdk8. >
>>>>>>> Regards,
>>>>>>> Manajit
>>>>>>>>
>>>>>>>> On 31-Jan-2018, at 2:40 AM, Sergey Bylokhov 
>>>>>>>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com> 
>>>>>>>> <mailto:sergey.bylokhov at oracle.com>> wrote:
>>>>>>>>
>>>>>>>> Hi, Manajit.
>>>>>>>> Did you check that it works properly in jdk8?
>>>>>>>>
>>>>>>>> I guess we need to set "WINDOW_FULLSCREENABLE" after we show 
>>>>>>>> the window for the first time, with one exception if the window 
>>>>>>>> is MAXIMIZED_BOTH.
>>>>>>>>
>>>>>>>> On 29/01/2018 04:39, Manajit Halder wrote:
>>>>>>>>> Hi All,
>>>>>>>>> Kindly review the fix for JDK10.
>>>>>>>>> Bug:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190767
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.00/
>>>>>>>>> Problem:
>>>>>>>>> In this problem two unrelated windows are created (first 
>>>>>>>>> window and second window). If the second window is created 
>>>>>>>>> when the first window is in fullscreen then the second window 
>>>>>>>>> will automatically be created in fullscreen mode. This is the 
>>>>>>>>> default behaviour with Cocoa windows. The second window 
>>>>>>>>> receives windowWillEnterFullScreen notification when the first 
>>>>>>>>> window is in fullscreen. windowWillEnterFullScreen 
>>>>>>>>> notification is system generated notification and there is no 
>>>>>>>>> way to prevent it.
>>>>>>>>> Above conclusion was made after debugging the issue to find 
>>>>>>>>> out if there is any way to prevent the 
>>>>>>>>> windowWillEnterFullScreen notification and also to find out if 
>>>>>>>>> it generated due to some existing java (generic and native) code.
>>>>>>>>> I wrote a simple Mac OS X application with 2 windows and 
>>>>>>>>> observed the same behaviour. The second window is created in 
>>>>>>>>> fullscreen mode if it is created when the first window is in 
>>>>>>>>> fullscreen. Whereas the second window is displayed normal if 
>>>>>>>>> the first window is in normal mode (not in fullscreen mode). 
>>>>>>>>> The only way found to prevent the second window going to 
>>>>>>>>> fullscreen is don’t set this behaviour for the second window.
>>>>>>>>> Fix:
>>>>>>>>> The behaviour is normal on Mac OS. But if we want to prevent 
>>>>>>>>> the second (all windows except the primary window) window to 
>>>>>>>>> automatically created in fullscreen mode then the following 
>>>>>>>>> fix can be applicable.
>>>>>>>>> By default all the Frames are set the WINDOW_FULLSCREENABLE 
>>>>>>>>> property and by default all frames receives fullscreen event 
>>>>>>>>> if the first frame is in fullscreen when it is created. Due to 
>>>>>>>>> this setting the second frame which is created on button click 
>>>>>>>>> goes to fullscreen on creation automatically. Mac OS 
>>>>>>>>> fullscreen event notifications are received in case the first 
>>>>>>>>> frame is in fullscreen and WINDOW_FULLSCREENABLE set for the 
>>>>>>>>> second frame.
>>>>>>>>> Only the first frame should have the WINDOW_FULLSCREENABLE 
>>>>>>>>> property set. The frames created in this case were ownerless 
>>>>>>>>> windows as mentioned earlier. Therefore it is not possible to 
>>>>>>>>> find out the owner of the current frame, it is null for all 
>>>>>>>>> the frames created. Hence the fix is if the current frame is 
>>>>>>>>> the first frame then set the property otherwise don’t set the 
>>>>>>>>> property WINDOW_FULLSCREENABLE.
>>>>>>>>> Regards,
>>>>>>>>> Manajit
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Best regards, Sergey.
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>>
>>>>
>>>>
>>
>>



More information about the awt-dev mailing list