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

Krishna Addepalli krishna.addepalli at oracle.com
Wed Mar 7 09:08:01 UTC 2018


Looks fine for me as well.

Thanks,
Krishna

Date: Tue, 6 Mar 2018 15:25:04 -0800
From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
To: Manajit Halder <manajit.halder at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> <AWT dev>[11] Review request for JDK-8190767:
	[macos] if JFrame is maximized on OS X, all new JFrames will be
	maximized by default
Message-ID: <7959f355-ae99-a8c5-cce0-d5d4d748dd32 at oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Looks fine, please make this test a macosx specific before the push( 
@requires tag)

On 06/03/2018 04:59, Manajit Halder wrote:
> Hi Sergey,
> 
> Thank you for the review comment. Modified the test case as per your 
> comment.
> Created issue https://bugs.openjdk.java.net/browse/JDK-8199116?for the 
> bug found by you.
> 
> Please review the webev:
> http://cr.openjdk.java.net/~mhalder/8190767/webrev.04/
> 
> Regards,
> Manajit
> 
>> On 05-Mar-2018, at 11:36 PM, Sergey Bylokhov 
>> <sergey.bylokhov at oracle.com <mailto:sergey.bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> On 26/02/2018 05:45, Manajit Halder wrote:
>>> Changed the fix as per Sergey?s review comment. Now both Frame and 
>>> Dialog are checked for resizibility before setting canFullScreen to true.
>>> Please review the modified webrev:
>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/
>>
>> There are small issues in the test;
>> - The Swing components should be created/accessed on EDT(see 
>> constructor of AllFramesMaximize and dispose)
>> - @test 8190767, I guess @bug tag missed.
>>
>> Also I found another bug by this testcase:
>> - Change the of the window from JFrame to JDialog at line 103
>> - Run the test.
>> - Click on the JButton which will open JDialog
>> - Click maximize on the JFrame
>> - Click on the JButton which will open JDialog again
>> - Two dialogs will try to get a focus in an endless loop, by switching 
>> between the spaces.
>>
>> Please file a CR for this.
>>
>>> Thanks,
>>> Manajit
>>>> On 17-Feb-2018, at 8:03 AM, Manajit Halder 
>>>> <manajit.halder at oracle.com 
>>>> <mailto:manajit.halder at oracle.com><mailto:manajit.halder at oracle.com>> wrote:
>>>>
>>>> Correcting the subject to indicate that the fix is for JDK 11.
>>>>
>>>> Regard,
>>>> Manajit
>>>>
>>>>> On 16-Feb-2018, at 9:48 PM, Kevin Rushforth 
>>>>> <kevin.rushforth at oracle.com 
>>>>> <mailto:kevin.rushforth at oracle.com><mailto:kevin.rushforth at oracle.com>> 
>>>>> wrote:
>>>>>
>>>>> Perhaps the subject should be changed to indicate that the fix is 
>>>>> for JDK 11 (not JDK 10 for which it is way too late)...
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> 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/<http://cr.openjdk.java.net/%7Emhalder/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><mailto:sergey.bylokhov at oracle.com>> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi, 
>>>>>>> Manajit.>http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/<http://cr.openjdk.java.net/%7Emhalder/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> 
>>>>>>>>> <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.
>>>>>>
>>>>
>>
>>
>> --
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.



More information about the awt-dev mailing list