From krishna.addepalli at oracle.com  Thu Feb  1 12:06:36 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 1 Feb 2018 04:06:36 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes in
	wayland mode
Message-ID: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>

Hi All, 

 

Please review a fix for JDK-8171000: https://bugs.openjdk.java.net/browse/JDK-8171000

Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/

 

The crash happens since XGetImage can return NULL in case of Wayland, which doesnot permit reading screen pixels outside the owning window. Added a null check to prevent the same, and also refactored and removed unnecessary code to make the function simpler.

 

Thanks,

Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180201/bc44dc18/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Feb  2 04:39:56 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 1 Feb 2018 20:39:56 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196006:
 java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
Message-ID: <822640d7-8509-42a3-a49a-2795fb565fd6@default>

Hi All, Please review a fix for the test bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8196006

 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196006/webrev.00/

 

Summary: This test fails on a hidpi monitor whereas passes on a normal monitor. Now the calculations are altered to take care of the scaling factor of the primary display unit. Now this test passes on both normal and hidpi monitors.

 

Thanks and regards,

Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180201/2b381e4e/attachment.html>

From Sergey.Bylokhov at oracle.com  Sat Feb  3 06:15:14 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 2 Feb 2018 22:15:14 -0800
Subject: <AWT Dev> <Swing Dev> [10] Review Request: 8196196 Headful
 tests should not be run in headless mode
In-Reply-To: <15cdff8e-43a5-944c-9ee9-aebb0118db91@oracle.com>
References: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
 <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>
 <15cdff8e-43a5-944c-9ee9-aebb0118db91@oracle.com>
Message-ID: <9abc2c42-cd44-5d61-2ea9-b6a39db7c976@oracle.com>

I do not know such syntax. But the easiest way to find such tests is to 
run them using "java.awt.headless". The open tests are mostly cleaned 
already. I'll start to update closed soon.

On 30/01/2018 12:06, Phil Race wrote:
> PS .. I have a question about identifying headful tests.
> 
> I assume that jtreg itself knows nothing about the meaning of @key 
> headful .. it
> just knows how to obey your command line option of -k:'!headful'
> 
> Many of the automated tests use applets. These would seem like they are 
> all headful ..
> How would one do the same for excluding applets without tediously adding 
> this keyword.
> 
> Is there jtreg syntax to exclude '.*html' ? Which might be one way to do 
> it.
> 
> -phil.
> 
> 
> On 01/30/2018 11:57 AM, Phil Race wrote:
>> You added @headful to BadDisplayTest, but also added this logic - why ?
>>
>>
>> ?public class BadDisplayTest{
>> ??? public static void main(String[] args) {
>> +?????? if (Boolean.getBoolean("java.awt.headless")) {
>> +?????????? return;
>> +?????? }
>>
>> -phil.
>>
>> On 01/30/2018 11:47 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review small test cleanup for jdk11.
>>>
>>> ?- "@key headful" was added to some tests which requires 
>>> DISPLAY/xorg/gtk/gnome etc.
>>> ?- Some swing tests were updated to skip unsupported look and feels, 
>>> for example GTK LookAndFeel can be installed(bundled) but is not 
>>> necessary supported.
>>>
>>> The final goal of this and some other future fixes is to run all 
>>> non-headfull tests in parallel and speedup the tests execution.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196196
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8196196/webrev.02/
>>>
>>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Feb  3 06:49:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 2 Feb 2018 22:49:33 -0800
Subject: <AWT Dev> [11] JDK-8196006:
 java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
In-Reply-To: <822640d7-8509-42a3-a49a-2795fb565fd6@default>
References: <822640d7-8509-42a3-a49a-2795fb565fd6@default>
Message-ID: <1f47506d-07ff-e70b-38c4-634824091a03@oracle.com>

Hi, Shashi.

Before this fix this test was executed on all screens on the system.
Why have you changed it to test only main screen?

If I understand the code correctly the test checks the size which is 
passed to frame.setMaximizedBounds() and the size which is returned by 
frame.getBounds(). In both cases the size should be in the users 
space(not in pixels). Why additional transform(added in the fix) is 
necessary?

On 01/02/2018 20:39, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review a fix for the test bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196006
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196006/webrev.00/
> 
> Summary: This test fails on a hidpi monitor whereas passes on a normal 
> monitor. Now the calculations are altered to take care of the scaling 
> factor of the primary display unit. Now this test passes on both normal 
> and hidpi monitors.
> 
> Thanks and regards,
> 
> Shashi
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Sat Feb  3 07:50:50 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 2 Feb 2018 23:50:50 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196006:
 java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
In-Reply-To: <1f47506d-07ff-e70b-38c4-634824091a03@oracle.com>
References: <822640d7-8509-42a3-a49a-2795fb565fd6@default>
 <1f47506d-07ff-e70b-38c4-634824091a03@oracle.com>
Message-ID: <3d579bab-e91d-4038-9c49-6d54c117dfcb@default>

Hi Sergey, Main reason to change the test to run on the main screen is that the test runs thro's different graphics configurations whereas keeping the AWT frame in the same main screen. This leads to wrong calculations. Also for the intent of the test it is not required to run on all the graphics configurations.

The problem is that getBounds() of the GraphicsConfiguration class returns the scaled size which is used as an initial input to set the maximized bounds by calling setMaximizedBounds(). As you said, frame.getBounds() returns the user space size. Hence we would need to transform it.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, February 3, 2018 12:20 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196006: java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails

Hi, Shashi.

Before this fix this test was executed on all screens on the system.
Why have you changed it to test only main screen?

If I understand the code correctly the test checks the size which is passed to frame.setMaximizedBounds() and the size which is returned by frame.getBounds(). In both cases the size should be in the users space(not in pixels). Why additional transform(added in the fix) is necessary?

On 01/02/2018 20:39, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review a fix for the test bug.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196006
> 
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196006/webrev.00/
> 
> Summary: This test fails on a hidpi monitor whereas passes on a normal 
> monitor. Now the calculations are altered to take care of the scaling 
> factor of the primary display unit. Now this test passes on both 
> normal and hidpi monitors.
> 
> Thanks and regards,
> 
> Shashi
> 


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Feb  3 07:56:37 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 2 Feb 2018 23:56:37 -0800
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes
 in wayland mode
In-Reply-To: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
References: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
Message-ID: <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>

Hi, Krishna.
The change of local types declarations looks reasonable, but I am not 
sure that C99 will be supported by all compilers which will be used to 
build jdk where this fix will be used.
I suggest to simplify the fix and add only one null check to it.

On 01/02/2018 04:06, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for JDK-8171000: 
> https://bugs.openjdk.java.net/browse/JDK-8171000
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/
> 
> The crash happens since XGetImage can return NULL in case of Wayland, 
> which doesnot permit reading screen pixels outside the owning window. 
> Added a null check to prevent the same, and also refactored and removed 
> unnecessary code to make the function simpler.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Sat Feb  3 08:07:36 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 3 Feb 2018 00:07:36 -0800
Subject: <AWT Dev> [11] JDK-8196006:
 java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
In-Reply-To: <3d579bab-e91d-4038-9c49-6d54c117dfcb@default>
References: <822640d7-8509-42a3-a49a-2795fb565fd6@default>
 <1f47506d-07ff-e70b-38c4-634824091a03@oracle.com>
 <3d579bab-e91d-4038-9c49-6d54c117dfcb@default>
Message-ID: <205f85c5-cceb-abff-f5fd-0fcc428310d3@oracle.com>

On 02/02/2018 23:50, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Main reason to change the test to run on the main screen is that the test runs thro's different graphics configurations whereas keeping the AWT frame in the same main screen. This leads to wrong calculations. Also for the intent of the test it is not required to run on all the graphics configurations.

Yes and it is one of the use-cases tested in the test: the frame located 
on one screen should be able to maximize to some other screen.

> 
> The problem is that getBounds() of the GraphicsConfiguration class returns the scaled size which is used as an initial input to set the maximized bounds by calling setMaximizedBounds(). As you said, frame.getBounds() returns the user space size. Hence we would need to transform it.

It sounds like a bug. At least on mac it works as expected on the retina 
screen. In the GraphicsConfiguration.getBounds() there are also attempts 
to scale down coordinates on linux/windows, it is unclear why it does 
not work.

> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 3, 2018 12:20 PM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8196006: java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
> 
> Hi, Shashi.
> 
> Before this fix this test was executed on all screens on the system.
> Why have you changed it to test only main screen?
> 
> If I understand the code correctly the test checks the size which is passed to frame.setMaximizedBounds() and the size which is returned by frame.getBounds(). In both cases the size should be in the users space(not in pixels). Why additional transform(added in the fix) is necessary?
> 
> On 01/02/2018 20:39, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a fix for the test bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196006
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196006/webrev.00/
>>
>> Summary: This test fails on a hidpi monitor whereas passes on a normal
>> monitor. Now the calculations are altered to take care of the scaling
>> factor of the primary display unit. Now this test passes on both
>> normal and hidpi monitors.
>>
>> Thanks and regards,
>>
>> Shashi
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Sat Feb  3 08:59:09 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sat, 3 Feb 2018 00:59:09 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196006:
 java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
In-Reply-To: <205f85c5-cceb-abff-f5fd-0fcc428310d3@oracle.com>
References: <822640d7-8509-42a3-a49a-2795fb565fd6@default>
 <1f47506d-07ff-e70b-38c4-634824091a03@oracle.com>
 <3d579bab-e91d-4038-9c49-6d54c117dfcb@default>
 <205f85c5-cceb-abff-f5fd-0fcc428310d3@oracle.com>
Message-ID: <0c741ef8-5b8e-463b-a2ca-57fdb22faa8c@default>

Hi Sergey, It looks a fix went in awt_Win32GraphicsDevice.cpp updating the size scaling under the bug JDK-8159062. I will get back with more details on it on Monday.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, February 3, 2018 1:38 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196006: java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails

On 02/02/2018 23:50, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Main reason to change the test to run on the main screen is that the test runs thro's different graphics configurations whereas keeping the AWT frame in the same main screen. This leads to wrong calculations. Also for the intent of the test it is not required to run on all the graphics configurations.

Yes and it is one of the use-cases tested in the test: the frame located on one screen should be able to maximize to some other screen.

> 
> The problem is that getBounds() of the GraphicsConfiguration class returns the scaled size which is used as an initial input to set the maximized bounds by calling setMaximizedBounds(). As you said, frame.getBounds() returns the user space size. Hence we would need to transform it.

It sounds like a bug. At least on mac it works as expected on the retina screen. In the GraphicsConfiguration.getBounds() there are also attempts to scale down coordinates on linux/windows, it is unclear why it does not work.

> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 3, 2018 12:20 PM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8196006: java/awt/Frame/SetMaximizedBounds/SetMaximizedBounds.java fails
> 
> Hi, Shashi.
> 
> Before this fix this test was executed on all screens on the system.
> Why have you changed it to test only main screen?
> 
> If I understand the code correctly the test checks the size which is passed to frame.setMaximizedBounds() and the size which is returned by frame.getBounds(). In both cases the size should be in the users space(not in pixels). Why additional transform(added in the fix) is necessary?
> 
> On 01/02/2018 20:39, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a fix for the test bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196006
>>
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196006/webrev.00/
>>
>> Summary: This test fails on a hidpi monitor whereas passes on a normal
>> monitor. Now the calculations are altered to take care of the scaling
>> factor of the primary display unit. Now this test passes on both
>> normal and hidpi monitors.
>>
>> Thanks and regards,
>>
>> Shashi
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Sun Feb  4 04:13:42 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sat, 3 Feb 2018 20:13:42 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes
 in wayland mode
In-Reply-To: <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>
References: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
 <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>
Message-ID: <ef1a1519-bd62-4c2b-aaab-9fe697f96e65@default>

Hi Sergey,

I'm aware of the C99 thing, so I looked around in the file before making those changes. For example, within the same function that I modified, I found variable declarations inside the for loop:
    for (reg = (image_region_type *) first_in_list( regions); reg;
          reg = (image_region_type *) next_in_list( regions))
     {
                 int32_t rect;
                 struct my_XRegion *vis_reg;

And also, in couple of other places within the same file, the some variables were declared within if blocks. That's when I moved the variable declarations to the point of use.

Thanks,
Krishna
-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, February 3, 2018 1:27 PM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode

Hi, Krishna.
The change of local types declarations looks reasonable, but I am not sure that C99 will be supported by all compilers which will be used to build jdk where this fix will be used.
I suggest to simplify the fix and add only one null check to it.

On 01/02/2018 04:06, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for JDK-8171000: 
> https://bugs.openjdk.java.net/browse/JDK-8171000
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/
> 
> The crash happens since XGetImage can return NULL in case of Wayland, 
> which doesnot permit reading screen pixels outside the owning window.
> Added a null check to prevent the same, and also refactored and 
> removed unnecessary code to make the function simpler.
> 
> Thanks,
> 
> Krishna
> 


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Feb  5 04:29:13 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sun, 4 Feb 2018 20:29:13 -0800
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes
 in wayland mode
In-Reply-To: <ef1a1519-bd62-4c2b-aaab-9fe697f96e65@default>
References: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
 <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>
 <ef1a1519-bd62-4c2b-aaab-9fe697f96e65@default>
Message-ID: <efc2b7d5-6a24-a28f-a0e2-4f4f02e3b380@oracle.com>

OK, then it looks fine.

On 03/02/2018 20:13, Krishna Addepalli wrote:
> Hi Sergey,
> 
> I'm aware of the C99 thing, so I looked around in the file before making those changes. For example, within the same function that I modified, I found variable declarations inside the for loop:
>      for (reg = (image_region_type *) first_in_list( regions); reg;
>            reg = (image_region_type *) next_in_list( regions))
>       {
>                   int32_t rect;
>                   struct my_XRegion *vis_reg;
> 
> And also, in couple of other places within the same file, the some variables were declared within if blocks. That's when I moved the variable declarations to the point of use.
> 
> Thanks,
> Krishna
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 3, 2018 1:27 PM
> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode
> 
> Hi, Krishna.
> The change of local types declarations looks reasonable, but I am not sure that C99 will be supported by all compilers which will be used to build jdk where this fix will be used.
> I suggest to simplify the fix and add only one null check to it.
> 
> On 01/02/2018 04:06, Krishna Addepalli wrote:
>> Hi All,
>>
>> Please review a fix for JDK-8171000:
>> https://bugs.openjdk.java.net/browse/JDK-8171000
>>
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/
>>
>> The crash happens since XGetImage can return NULL in case of Wayland,
>> which doesnot permit reading screen pixels outside the owning window.
>> Added a null check to prevent the same, and also refactored and
>> removed unnecessary code to make the function simpler.
>>
>> Thanks,
>>
>> Krishna
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From manajit.halder at oracle.com  Mon Feb  5 07:45:23 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 5 Feb 2018 13:15:23 +0530
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes
 in wayland mode
In-Reply-To: <efc2b7d5-6a24-a28f-a0e2-4f4f02e3b380@oracle.com>
References: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
 <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>
 <ef1a1519-bd62-4c2b-aaab-9fe697f96e65@default>
 <efc2b7d5-6a24-a28f-a0e2-4f4f02e3b380@oracle.com>
Message-ID: <6355EE2B-A0FF-4E60-8220-7625CF0DB822@oracle.com>

Looks good to me
+1

Regards,
Manajit

> On 05-Feb-2018, at 9:59 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> OK, then it looks fine.
> 
> On 03/02/2018 20:13, Krishna Addepalli wrote:
>> Hi Sergey,
>> I'm aware of the C99 thing, so I looked around in the file before making those changes. For example, within the same function that I modified, I found variable declarations inside the for loop:
>>     for (reg = (image_region_type *) first_in_list( regions); reg;
>>           reg = (image_region_type *) next_in_list( regions))
>>      {
>>                  int32_t rect;
>>                  struct my_XRegion *vis_reg;
>> And also, in couple of other places within the same file, the some variables were declared within if blocks. That's when I moved the variable declarations to the point of use.
>> Thanks,
>> Krishna
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, February 3, 2018 1:27 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode
>> Hi, Krishna.
>> The change of local types declarations looks reasonable, but I am not sure that C99 will be supported by all compilers which will be used to build jdk where this fix will be used.
>> I suggest to simplify the fix and add only one null check to it.
>> On 01/02/2018 04:06, Krishna Addepalli wrote:
>>> Hi All,
>>> 
>>> Please review a fix for JDK-8171000:
>>> https://bugs.openjdk.java.net/browse/JDK-8171000
>>> 
>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/
>>> 
>>> The crash happens since XGetImage can return NULL in case of Wayland,
>>> which doesnot permit reading screen pixels outside the owning window.
>>> Added a null check to prevent the same, and also refactored and
>>> removed unnecessary code to make the function simpler.
>>> 
>>> Thanks,
>>> 
>>> Krishna
>>> 
>> --
>> Best regards, Sergey.
> 
> 
> -- 
> Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Tue Feb  6 08:27:27 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 6 Feb 2018 00:27:27 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196841: [TEST_BUG]
 "java/awt/Component/SetEnabledPerfomance/SetEnabledPerformance.java" fails
Message-ID: <2f41839f-87d0-4bbb-a032-aaa3c88ad991@default>

Hi All, Please review a fix for the below test bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8196841

 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196841/webrev.00/

 

Summary: The original test creates a pool of button objects on the stack and throws 'stackOverflowError' when the stack runs out of memory. The fix sets a higher stack size for the test to run and now it passes.

 

Thanks and regards,
Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180206/9fa73f53/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Feb  6 09:53:04 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara veerabhadraiah)
Date: Tue, 6 Feb 2018 15:23:04 +0530
Subject: <AWT Dev> [11] JDK-8196841: [TEST_BUG]
 "java/awt/Component/SetEnabledPerfomance/SetEnabledPerformance.java" fails
In-Reply-To: <2f41839f-87d0-4bbb-a032-aaa3c88ad991@default>
References: <2f41839f-87d0-4bbb-a032-aaa3c88ad991@default>
Message-ID: <BE28C2CA-097F-40AE-A7F8-4EA16BBD7CEC@oracle.com>

Hi All, There is a recursion code at AWTEventMulticaster.java that is causing the stack to overflow which is the real reason for the ?stackOverflowError'. Hence please hold this review until I fix the real problem.

Thanks and regards,
Shashi

> On 06-Feb-2018, at 1:57 PM, Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> wrote:
> 
> Hi All, Please review a fix for the below test bug.
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196841 <https://bugs.openjdk.java.net/browse/JDK-8196841>
>  
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196841/webrev.00/ <http://cr.openjdk.java.net/~sveerabhadra/8196841/webrev.00/>
>  
> Summary: The original test creates a pool of button objects on the stack and throws ?stackOverflowError? when the stack runs out of memory. The fix sets a higher stack size for the test to run and now it passes.
>  
> Thanks and regards,
> Shashi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180206/68b6e4a9/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Feb  9 00:28:45 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Feb 2018 16:28:45 -0800
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes
 in wayland mode
In-Reply-To: <efc2b7d5-6a24-a28f-a0e2-4f4f02e3b380@oracle.com>
References: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
 <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>
 <ef1a1519-bd62-4c2b-aaab-9fe697f96e65@default>
 <efc2b7d5-6a24-a28f-a0e2-4f4f02e3b380@oracle.com>
Message-ID: <1ec56c48-aaa1-d3f0-e0e8-4dae4ca0d4aa@oracle.com>

Actually it breaks the build on solaris sparc, please fix it:

jib > 
"/work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c", 
line 405: error: declaration statement is not allowed in for-loop 
initialization (E_DECLARATION_IN_FOR)
jib > 
"/work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c", 
line 409: error: declaration statement is not allowed in for-loop 
initialization (E_DECLARATION_IN_FOR)
jib > cc: acomp failed for 
/work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c
jib > make[3]: *** 
[work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/build/solaris-sparcv9/support/native/java.desktop/libawt_xawt/multiVis.o] 
Error 1

On 04/02/2018 20:29, Sergey Bylokhov wrote:
> OK, then it looks fine.
> 
> On 03/02/2018 20:13, Krishna Addepalli wrote:
>> Hi Sergey,
>>
>> I'm aware of the C99 thing, so I looked around in the file before 
>> making those changes. For example, within the same function that I 
>> modified, I found variable declarations inside the for loop:
>> ???? for (reg = (image_region_type *) first_in_list( regions); reg;
>> ?????????? reg = (image_region_type *) next_in_list( regions))
>> ????? {
>> ????????????????? int32_t rect;
>> ????????????????? struct my_XRegion *vis_reg;
>>
>> And also, in couple of other places within the same file, the some 
>> variables were declared within if blocks. That's when I moved the 
>> variable declarations to the point of use.
>>
>> Thanks,
>> Krishna
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, February 3, 2018 1:27 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() 
>> crashes in wayland mode
>>
>> Hi, Krishna.
>> The change of local types declarations looks reasonable, but I am not 
>> sure that C99 will be supported by all compilers which will be used to 
>> build jdk where this fix will be used.
>> I suggest to simplify the fix and add only one null check to it.
>>
>> On 01/02/2018 04:06, Krishna Addepalli wrote:
>>> Hi All,
>>>
>>> Please review a fix for JDK-8171000:
>>> https://bugs.openjdk.java.net/browse/JDK-8171000
>>>
>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/
>>>
>>> The crash happens since XGetImage can return NULL in case of Wayland,
>>> which doesnot permit reading screen pixels outside the owning window.
>>> Added a null check to prevent the same, and also refactored and
>>> removed unnecessary code to make the function simpler.
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>
> 
> 


-- 
Best regards, Sergey.

From jayathirth.d.v at oracle.com  Fri Feb  9 04:00:55 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 8 Feb 2018 20:00:55 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes
 in wayland mode
In-Reply-To: <1ec56c48-aaa1-d3f0-e0e8-4dae4ca0d4aa@oracle.com>
References: <24ec9acb-692b-47d4-bf64-6cfe698d7db5@default>
 <a6af9e0e-29f4-6ab5-477b-c11891bea670@oracle.com>
 <ef1a1519-bd62-4c2b-aaab-9fe697f96e65@default>
 <efc2b7d5-6a24-a28f-a0e2-4f4f02e3b380@oracle.com>
 <1ec56c48-aaa1-d3f0-e0e8-4dae4ca0d4aa@oracle.com>
Message-ID: <f82d0095-d294-4a41-9635-7142be3b77f5@default>

Hello Krishna,

FYI. Build is failing on OEL7 also.
/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c:405:5: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
jib >      for (image_region_type* reg = (image_region_type *) first_in_list( regions); reg;

/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c:409:17: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
jib >                  for (int32_t rect = 0; rect < vis_reg->numRects; rect++)

Thanks,
Jay

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, February 09, 2018 5:59 AM
To: Krishna Addepalli; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture() crashes in wayland mode

Actually it breaks the build on solaris sparc, please fix it:

jib >
"/work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c",
line 405: error: declaration statement is not allowed in for-loop initialization (E_DECLARATION_IN_FOR) jib > "/work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c",
line 409: error: declaration statement is not allowed in for-loop initialization (E_DECLARATION_IN_FOR) jib > cc: acomp failed for /work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/open/src/java.desktop/unix/native/libawt_xawt/awt/multiVis.c
jib > make[3]: ***
[work_dir/49831a9a-88b9-4acc-a9f6-f21c977aa801/workspace/build/solaris-sparcv9/support/native/java.desktop/libawt_xawt/multiVis.o]
Error 1

On 04/02/2018 20:29, Sergey Bylokhov wrote:
> OK, then it looks fine.
> 
> On 03/02/2018 20:13, Krishna Addepalli wrote:
>> Hi Sergey,
>>
>> I'm aware of the C99 thing, so I looked around in the file before 
>> making those changes. For example, within the same function that I 
>> modified, I found variable declarations inside the for loop:
>> ???? for (reg = (image_region_type *) first_in_list( regions); reg;
>> ?????????? reg = (image_region_type *) next_in_list( regions))
>> ????? {
>> ????????????????? int32_t rect;
>> ????????????????? struct my_XRegion *vis_reg;
>>
>> And also, in couple of other places within the same file, the some 
>> variables were declared within if blocks. That's when I moved the 
>> variable declarations to the point of use.
>>
>> Thanks,
>> Krishna
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, February 3, 2018 1:27 PM
>> To: Krishna Addepalli <krishna.addepalli at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8171000]Robot.createScreenCapture()
>> crashes in wayland mode
>>
>> Hi, Krishna.
>> The change of local types declarations looks reasonable, but I am not 
>> sure that C99 will be supported by all compilers which will be used 
>> to build jdk where this fix will be used.
>> I suggest to simplify the fix and add only one null check to it.
>>
>> On 01/02/2018 04:06, Krishna Addepalli wrote:
>>> Hi All,
>>>
>>> Please review a fix for JDK-8171000:
>>> https://bugs.openjdk.java.net/browse/JDK-8171000
>>>
>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8171000/webrev00/
>>>
>>> The crash happens since XGetImage can return NULL in case of 
>>> Wayland, which doesnot permit reading screen pixels outside the owning window.
>>> Added a null check to prevent the same, and also refactored and 
>>> removed unnecessary code to make the function simpler.
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
> 
> 


--
Best regards, Sergey.

From philip.race at oracle.com  Mon Feb 12 05:14:34 2018
From: philip.race at oracle.com (Philip Race)
Date: Sun, 11 Feb 2018 21:14:34 -0800
Subject: <AWT Dev> RFR: 8197546: Fix for 8171000 breaks Solaris + Linux
	builds
Message-ID: <5A8122BA.9090600@oracle.com>

Fix for broken Solaris + Linux builds
Bug: https://bugs.openjdk.java.net/browse/JDK-8197546
Webrev: http://cr.openjdk.java.net/~prr/8197546/

Fix verified using "official" build systems for all platforms.

-phil.

From jayathirth.d.v at oracle.com  Mon Feb 12 06:07:29 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Sun, 11 Feb 2018 22:07:29 -0800 (PST)
Subject: <AWT Dev> RFR: 8197546: Fix for 8171000 breaks Solaris + Linux
 builds
In-Reply-To: <5A8122BA.9090600@oracle.com>
References: <5A8122BA.9090600@oracle.com>
Message-ID: <f2e0ae3a-0fa9-4ec9-a687-aed79bf0ff8b@default>

Changes are fine.

-----Original Message-----
From: Philip Race 
Sent: Monday, February 12, 2018 10:45 AM
To: awt-dev at openjdk.java.net
Subject: <AWT Dev> RFR: 8197546: Fix for 8171000 breaks Solaris + Linux builds

Fix for broken Solaris + Linux builds
Bug: https://bugs.openjdk.java.net/browse/JDK-8197546
Webrev: http://cr.openjdk.java.net/~prr/8197546/

Fix verified using "official" build systems for all platforms.

-phil.

From manajit.halder at oracle.com  Mon Feb 12 13:13:16 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 12 Feb 2018 18:43:16 +0530
Subject: <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
In-Reply-To: <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
Message-ID: <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>

Hi Sergey,

Thank you for the review comment. I have changed the fix as per your comment. Please review the webvrev.
http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/>

The issue is not reproducible in jdk8.

Regards,
Manajit
 
> 

> On 31-Jan-2018, at 2:40 AM, Sergey Bylokhov <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180212/aec281d6/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Feb 12 14:42:17 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 12 Feb 2018 06:42:17 -0800
Subject: <AWT Dev> RFR: 8197546: Fix for 8171000 breaks Solaris + Linux
 builds
In-Reply-To: <f2e0ae3a-0fa9-4ec9-a687-aed79bf0ff8b@default>
References: <5A8122BA.9090600@oracle.com>
 <f2e0ae3a-0fa9-4ec9-a687-aed79bf0ff8b@default>
Message-ID: <c8534b32-4046-81ac-efe6-f4e09c3c8537@oracle.com>

+1

On 11/02/2018 22:07, Jayathirth D V wrote:
> Changes are fine.
> 
> -----Original Message-----
> From: Philip Race
> Sent: Monday, February 12, 2018 10:45 AM
> To: awt-dev at openjdk.java.net
> Subject: <AWT Dev> RFR: 8197546: Fix for 8171000 breaks Solaris + Linux builds
> 
> Fix for broken Solaris + Linux builds
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197546
> Webrev: http://cr.openjdk.java.net/~prr/8197546/
> 
> Fix verified using "official" build systems for all platforms.
> 
> -phil.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Feb 14 02:59:15 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Feb 2018 18:59:15 -0800
Subject: <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
In-Reply-To: <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
Message-ID: <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>

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>> 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.

From jayathirth.d.v at oracle.com  Wed Feb 14 10:36:56 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 14 Feb 2018 02:36:56 -0800 (PST)
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
Message-ID: <7c327feb-762b-4cd5-b702-d7d741f926de@default>

Hello All,

 

Please review the following fix in JDK11 :

 

Bug : https://bugs.openjdk.java.net/browse/JDK-8197926 

Webrev : http://cr.openjdk.java.net/~jdv/8197926/webrev.00/ 

 

Issue: If we enable HiDPi setting in Windows to approximately 125% or more, java/awt/dnd/ImageTransferTest/ImageTransferTest.java times out and doesn't dispose the created Java windows.

 

Root cause : In Windows because of default insets parameters, frames created in test case overlap and over that if we enable HiDPi setting the mouse drag and drop calculation is not proper and this results in time out and created frames are not disposed properly.

 

Solution: The default frame insets behave differently in different platforms(Windows, Unix & MacOS). Since the main objective of test case is to transfer image from one frame to another and validate, there is no need for us to have frame with insets. Making the frame Undecorated results in uniform behavior across all platforms and test case passes. I have verified the test case after change in Windows, Ubuntu and MacOS and there are no side effects.

 

Observation : In the test case we are creating second frame using "ProcessCommunicator.executeChildProcess()".  If we want to reproduce the issue using "-Dsun.java2d.uiScale" from command prompt the ProcessCommunicator will pick default scale values and second window will not be of required dimensions. We can pass "-Dsun.java2d.uiScale" value to ProcessCommunicator.executeChildProcess() like (ProcessCommunicator.executeChildProcess(ImageDropTarget.class, classpath+" -Dsun.java2d.uiScale=2", args)) but I didn't find a way to get "uiScale" value passed in command prompt into the test case. System.getProperty(sun.java2d.uiScale) returns null. 

 

If there is a way to get uiScale value passed in command prompt in the test case we can pass it to ProcessCommunicator.executeChildProcess() so that we can reproduce the issue by just passing VM option to jtreg. As of now to reproduce the issue we should go to Personalize->Display and change HiDPi setting.

 

Thanks,

Jay

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180214/57f483d5/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Feb 14 22:56:33 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Feb 2018 14:56:33 -0800
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <7c327feb-762b-4cd5-b702-d7d741f926de@default>
References: <7c327feb-762b-4cd5-b702-d7d741f926de@default>
Message-ID: <5601237c-bd7e-0ad5-6ce9-7698f16d9d05@oracle.com>

Hi, Jay.
I suppose the test should dispose the frames as well(even if it fails).
I tried to emulate test failure, and got an open frame when the test 
itself and jtreg exit.

On 14/02/2018 02:36, Jayathirth D V wrote:
> Hello All,
> 
> Please review the following fix in JDK11 :
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8197926
> 
> Webrev : http://cr.openjdk.java.net/~jdv/8197926/webrev.00/
> 
> _Issue:_ If we enable HiDPi setting in Windows to approximately 125% or 
> more, java/awt/dnd/ImageTransferTest/ImageTransferTest.java times out 
> and doesn?t dispose the created Java windows.
> 
> _Root cause_ : In Windows because of default insets parameters, frames 
> created in test case overlap and over that if we enable HiDPi setting 
> the mouse drag and drop calculation is not proper and this results in 
> time out and created frames are not disposed properly.
> 
> _Solution:_ The default frame insets behave differently in different 
> platforms(Windows, Unix & MacOS). Since the main objective of test case 
> is to transfer image from one frame to another and validate, there is no 
> need for us to have frame with insets. Making the frame Undecorated 
> results in uniform behavior across all platforms and test case passes. I 
> have verified the test case after change in Windows, Ubuntu and MacOS 
> and there are no side effects.
> 
> _Observation_ : In the test case we are creating second frame using 
> ?ProcessCommunicator.executeChildProcess()?. ?If we want to reproduce 
> the issue using ?-Dsun.java2d.uiScale? from command prompt the 
> ProcessCommunicator will pick default scale values and second window 
> will not be of required dimensions. We can pass ?-Dsun.java2d.uiScale? 
> value to ProcessCommunicator.executeChildProcess() like 
> (ProcessCommunicator.executeChildProcess(ImageDropTarget.class, 
> classpath+" -Dsun.java2d.uiScale=2", args)) but I didn?t find a way to 
> get ?uiScale? value passed in command prompt into the test case. 
> System.getProperty(sun.java2d.uiScale) returns null.
> 
> If there is a way to get uiScale value passed in command prompt in the 
> test case we can pass it to ProcessCommunicator.executeChildProcess() so 
> that we can reproduce the issue by just passing VM option to jtreg. As 
> of now to reproduce the issue we should go to Personalize->Display and 
> change HiDPi setting.
> 
> Thanks,
> 
> Jay
> 


-- 
Best regards, Sergey.

From jayathirth.d.v at oracle.com  Thu Feb 15 09:46:57 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 15 Feb 2018 01:46:57 -0800 (PST)
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <5601237c-bd7e-0ad5-6ce9-7698f16d9d05@oracle.com>
References: <7c327feb-762b-4cd5-b702-d7d741f926de@default>
 <5601237c-bd7e-0ad5-6ce9-7698f16d9d05@oracle.com>
Message-ID: <b379b467-ad8b-46e6-aef0-f9ab1471a163@default>

Hi Sergey,

Thanks for your inputs.
I tried different failure scenarios inside test like making comparing images fail but all the times frames are getting disposed.
Could you please elaborate in which scenario exactly you are seeing frame not getting disposed?

But I have still added explicit frame.dispose() at places to make sure that we dispose the created frames.
Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8197926/webrev.01/ 

Also in continuation to what we discussed offline, I used -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command prompt. But in this case also System.getProperty("sun.java2d.uiScale") returned null in test case. So I was not able to pass uiScale mentioned in command prompt to ProcessCommunicator in test case.

Thanks,
Jay

-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, February 15, 2018 4:27 AM
To: Jayathirth D V; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting

Hi, Jay.
I suppose the test should dispose the frames as well(even if it fails).
I tried to emulate test failure, and got an open frame when the test itself and jtreg exit.

On 14/02/2018 02:36, Jayathirth D V wrote:
> Hello All,
> 
> Please review the following fix in JDK11 :
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8197926
> 
> Webrev : http://cr.openjdk.java.net/~jdv/8197926/webrev.00/
> 
> _Issue:_ If we enable HiDPi setting in Windows to approximately 125% 
> or more, java/awt/dnd/ImageTransferTest/ImageTransferTest.java times 
> out and doesn't dispose the created Java windows.
> 
> _Root cause_ : In Windows because of default insets parameters, frames 
> created in test case overlap and over that if we enable HiDPi setting 
> the mouse drag and drop calculation is not proper and this results in 
> time out and created frames are not disposed properly.
> 
> _Solution:_ The default frame insets behave differently in different 
> platforms(Windows, Unix & MacOS). Since the main objective of test 
> case is to transfer image from one frame to another and validate, 
> there is no need for us to have frame with insets. Making the frame 
> Undecorated results in uniform behavior across all platforms and test 
> case passes. I have verified the test case after change in Windows, 
> Ubuntu and MacOS and there are no side effects.
> 
> _Observation_ : In the test case we are creating second frame using 
> "ProcessCommunicator.executeChildProcess()". ?If we want to reproduce 
> the issue using "-Dsun.java2d.uiScale" from command prompt the 
> ProcessCommunicator will pick default scale values and second window 
> will not be of required dimensions. We can pass "-Dsun.java2d.uiScale"
> value to ProcessCommunicator.executeChildProcess() like 
> (ProcessCommunicator.executeChildProcess(ImageDropTarget.class,
> classpath+" -Dsun.java2d.uiScale=2", args)) but I didn't find a way to
> get "uiScale" value passed in command prompt into the test case. 
> System.getProperty(sun.java2d.uiScale) returns null.
> 
> If there is a way to get uiScale value passed in command prompt in the 
> test case we can pass it to ProcessCommunicator.executeChildProcess() 
> so that we can reproduce the issue by just passing VM option to jtreg. 
> As of now to reproduce the issue we should go to Personalize->Display 
> and change HiDPi setting.
> 
> Thanks,
> 
> Jay
> 


--
Best regards, Sergey.

From krishna.addepalli at oracle.com  Thu Feb 15 12:16:02 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Thu, 15 Feb 2018 04:16:02 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events
 arrive out of sequence
Message-ID: <18b39b46-2de0-4bd2-86ea-7ed545cf76df@default>

Hi All, 

 

Please review a fix for  JDK-8152974: https://bugs.openjdk.java.net/browse/JDK-8152974

Webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev00/

 

The problem is when the events arrive out of sequence, the sequenced event's dispatch loop assumes that the sequenced events are pushed into the queue together, which may not be the case, and this blocks the event queue. The fix is to continue to process all the events, which ultimately leads to the processing of the SequencedEvents in their order of creation.

 

Thanks,

Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180215/5f01e86a/attachment.html>

From sergey.bylokhov at oracle.com  Thu Feb 15 21:57:49 2018
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Feb 2018 13:57:49 -0800 (PST)
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
Message-ID: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>

Hi, Jay.
> I tried different failure scenarios inside test like making comparing
> images fail but all the times frames are getting disposed.
> Could you please elaborate in which scenario exactly you are seeing
> frame not getting disposed?

I run the version of the test before your fix, and it leaves one of the frame of the screen.

> 
> But I have still added explicit frame.dispose() at places to make sure
> that we dispose the created frames.
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/ 
> 
> Also in continuation to what we discussed offline, I used
> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command
> prompt. But in this case also System.getProperty("sun.java2d.uiScale")
> returned null in test case. So I was not able to pass uiScale
> mentioned in command prompt to ProcessCommunicator in test case.

I tested it using this command line:
../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10" -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/  open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java

Plus this change in the test:
    public static void main(String[] arg) throws Exception {
+       String prop = System.getProperty("sun.java2d.uiScale");
+	System.err.println(prop);

It prints 10 in the log.


From Sergey.Bylokhov at oracle.com  Thu Feb 15 22:30:03 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Feb 2018 14:30:03 -0800
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
 events arrive out of sequence
In-Reply-To: <18b39b46-2de0-4bd2-86ea-7ed545cf76df@default>
References: <18b39b46-2de0-4bd2-86ea-7ed545cf76df@default>
Message-ID: <908bf597-c40c-977e-cde4-258c39bbf27c@oracle.com>

Hi, Krishna.
Can you please provide more details why the test hang, it post two 
SequencedEvents out of order, the first waits when the second will be 
dispatched, why it hangs forever?

On 15/02/2018 04:16, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for ?JDK-8152974: 
> https://bugs.openjdk.java.net/browse/JDK-8152974
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev00/
> 
> The problem is when the events arrive out of sequence, the sequenced 
> event?s dispatch loop assumes that the sequenced events are pushed into 
> the queue together, which may not be the case, and this blocks the event 
> queue. The fix is to continue to process all the events, which 
> ultimately leads to the processing of the SequencedEvents in their order 
> of creation.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Thu Feb 15 22:49:27 2018
From: philip.race at oracle.com (Philip Race)
Date: Thu, 15 Feb 2018 14:49:27 -0800
Subject: <AWT Dev> <Swing Dev> [10] Review Request: 8196196 Headful
 tests should not be run in headless mode
In-Reply-To: <9abc2c42-cd44-5d61-2ea9-b6a39db7c976@oracle.com>
References: <8d05a5a0-9d67-89a2-16fa-6c60bb315754@oracle.com>
 <4599d00a-8012-7038-b215-cfa83c7fdf81@oracle.com>
 <15cdff8e-43a5-944c-9ee9-aebb0118db91@oracle.com>
 <9abc2c42-cd44-5d61-2ea9-b6a39db7c976@oracle.com>
Message-ID: <5A860E77.2060101@oracle.com>

Approved.

-phil.

On 2/2/18, 10:15 PM, Sergey Bylokhov wrote:
> I do not know such syntax. But the easiest way to find such tests is 
> to run them using "java.awt.headless". The open tests are mostly 
> cleaned already. I'll start to update closed soon.
>
> On 30/01/2018 12:06, Phil Race wrote:
>> PS .. I have a question about identifying headful tests.
>>
>> I assume that jtreg itself knows nothing about the meaning of @key 
>> headful .. it
>> just knows how to obey your command line option of -k:'!headful'
>>
>> Many of the automated tests use applets. These would seem like they 
>> are all headful ..
>> How would one do the same for excluding applets without tediously 
>> adding this keyword.
>>
>> Is there jtreg syntax to exclude '.*html' ? Which might be one way to 
>> do it.
>>
>> -phil.
>>
>>
>> On 01/30/2018 11:57 AM, Phil Race wrote:
>>> You added @headful to BadDisplayTest, but also added this logic - why ?
>>>
>>>
>>>  public class BadDisplayTest{
>>>     public static void main(String[] args) {
>>> +       if (Boolean.getBoolean("java.awt.headless")) {
>>> +           return;
>>> +       }
>>>
>>> -phil.
>>>
>>> On 01/30/2018 11:47 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review small test cleanup for jdk11.
>>>>
>>>>  - "@key headful" was added to some tests which requires 
>>>> DISPLAY/xorg/gtk/gnome etc.
>>>>  - Some swing tests were updated to skip unsupported look and 
>>>> feels, for example GTK LookAndFeel can be installed(bundled) but is 
>>>> not necessary supported.
>>>>
>>>> The final goal of this and some other future fixes is to run all 
>>>> non-headfull tests in parallel and speedup the tests execution.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196196
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8196196/webrev.02/
>>>>
>>>>
>>>
>>
>
>

From semyon.sadetsky at oracle.com  Fri Feb 16 02:09:11 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Feb 2018 18:09:11 -0800
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
 events arrive out of sequence
In-Reply-To: <18b39b46-2de0-4bd2-86ea-7ed545cf76df@default>
References: <18b39b46-2de0-4bd2-86ea-7ed545cf76df@default>
Message-ID: <32533ac8-0007-668f-f691-fab84a8fac84@oracle.com>

Hi Krishna,

Unlikely this will work for several app contexts.

You need to find the root cause why the sequenced events get mixed up 
and fix it.

--Semyon


On 02/15/2018 04:16 AM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for ?JDK-8152974: 
> https://bugs.openjdk.java.net/browse/JDK-8152974
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8152974/webrev00/>
>
> The problem is when the events arrive out of sequence, the sequenced 
> event?s dispatch loop assumes that the sequenced events are pushed 
> into the queue together, which may not be the case, and this blocks 
> the event queue. The fix is to continue to process all the events, 
> which ultimately leads to the processing of the SequencedEvents in 
> their order of creation.
>
> Thanks,
>
> Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180215/a3b04c00/attachment-0001.html>

From prem.balakrishnan at oracle.com  Fri Feb 16 05:57:41 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Thu, 15 Feb 2018 21:57:41 -0800 (PST)
Subject: <AWT Dev> [11] Review Request: JDK-8196441
 java/awt/Modal/ToBack/*.java tests fail
Message-ID: <f7e3f7dd-c89d-4275-b0d3-b07265eff22a@default>

Hi All,

 

Please review the following fix for JDK 11 :

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8196441 

 

Webrev: http://cr.openjdk.java.net/~pkbalakr/8196441/webrev.00/ 

 

Robot mouse move in these tests, placed the mouse cursor exactly on the edge of the Frame/Dialog, 

due to which the cursor changed to resize cursor and mouse press didn't work as expected. 

Proposed fix sets the Frame/Dialog resizable to false.

 

Regards,

Prem

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180215/b245b0c7/attachment.html>

From prasanta.sadhukhan at oracle.com  Fri Feb 16 06:56:23 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 16 Feb 2018 12:26:23 +0530
Subject: <AWT Dev> [11] Review Request: JDK-8196441
 java/awt/Modal/ToBack/*.java tests fail
In-Reply-To: <f7e3f7dd-c89d-4275-b0d3-b07265eff22a@default>
References: <f7e3f7dd-c89d-4275-b0d3-b07265eff22a@default>
Message-ID: <c8191edb-3b28-bdf0-5981-459ffb93819f@oracle.com>

Hi Prem,

I still see java/awt/Modal/ToBack/ToBackAppModal1Test.java (1st test in 
the list) fails in ubuntu16.04. Did you run all the tests listed there 
in JBS?

Regards
Prasanta
On 2/16/2018 11:27 AM, Prem Balakrishnan wrote:
>
> Hi All,
>
> Please review the following fix for JDK 11 :
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196441
>
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196441/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8196441/webrev.00/>
>
> Robot mouse move in these tests, placed the mouse cursor exactly on 
> the edge of the Frame/Dialog,
>
> due to which the cursor changed to resize cursor and mouse press 
> didn?t work as expected.
>
> Proposed fix sets the Frame/Dialog resizable to false.
>
> Regards,
>
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180216/ea1f8596/attachment.html>

From jayathirth.d.v at oracle.com  Fri Feb 16 07:33:44 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Thu, 15 Feb 2018 23:33:44 -0800 (PST)
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
Message-ID: <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>

Hi Sergey,

Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.

Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8197926/webrev.02/ 

Thanks,
Jay

-----Original Message-----
From: Sergey Bylokhov 
Sent: Friday, February 16, 2018 3:28 AM
To: Jayathirth D V
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting

Hi, Jay.
> I tried different failure scenarios inside test like making comparing 
> images fail but all the times frames are getting disposed.
> Could you please elaborate in which scenario exactly you are seeing 
> frame not getting disposed?

I run the version of the test before your fix, and it leaves one of the frame of the screen.

> 
> But I have still added explicit frame.dispose() at places to make sure 
> that we dispose the created frames.
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
> 
> Also in continuation to what we discussed offline, I used 
> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command 
> prompt. But in this case also System.getProperty("sun.java2d.uiScale")
> returned null in test case. So I was not able to pass uiScale 
> mentioned in command prompt to ProcessCommunicator in test case.

I tested it using this command line:
../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10" -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/  open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java

Plus this change in the test:
    public static void main(String[] arg) throws Exception {
+       String prop = System.getProperty("sun.java2d.uiScale");
+	System.err.println(prop);

It prints 10 in the log.


From krishna.addepalli at oracle.com  Fri Feb 16 08:42:06 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Feb 2018 00:42:06 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
Message-ID: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>

Hi Sergey,

Here is my understanding:
When a SequencedEvent, detects that it is not the first event in the list, it tries to dispatch events to ensure that the event that is before it gets processed first. All SequencedEvents are created with the ID - "java.awt.event.FocusEvent.FOCUS_LAST + 1".
Now, when it tries to dispatch, it calls the pumpEvents as below:
                     edt.pumpEvents(SentEvent.ID, new Conditional() {
                             public boolean evaluate() {
                                 return !SequencedEvent.this.isFirstOrDisposed();
                             }
                         });

The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.
Ideally, the code should have pumped events, with its own id, since all the sequenced events are created with that id. When I made this change and tested, it did not hang.
However, if sequenced events are not posted immediately one after the other, even this would fail, since it would expect that the next event that is scheduled should be of SequencedEvent type. 

I have removed the "id" parameter in pumpEvents, which effectively means to process all events till the current SequencedEvent becomes the first one in the list, at which point, it would process itself.

@Semyon,

I don't think the problem is with multiple AppContexts. I have modified the test case to create a second AppContext, and post few events in that context. In that case, even Java8 was able to run to completion without any problems.
Attached the test case for your reference. 
Let me know if there is a problem with the testcase, or we can exercise the multiple AppContexts in a better way.

Thanks,
Krishna

Message: 3
Date: Thu, 15 Feb 2018 14:30:03 -0800
From: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
To: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
	sequenced events arrive out of sequence
Message-ID: <908bf597-c40c-977e-cde4-258c39bbf27c at oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi, Krishna.
Can you please provide more details why the test hang, it post two SequencedEvents out of order, the first waits when the second will be dispatched, why it hangs forever?

On 15/02/2018 04:16, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for ?JDK-8152974: 
> https://bugs.openjdk.java.net/browse/JDK-8152974
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev00/
> 
> The problem is when the events arrive out of sequence, the sequenced 
> event?s dispatch loop assumes that the sequenced events are pushed 
> into the queue together, which may not be the case, and this blocks 
> the event queue. The fix is to continue to process all the events, 
> which ultimately leads to the processing of the SequencedEvents in 
> their order of creation.
> 
> Thanks,
> 
> Krishna
> 


--
Best regards, Sergey.


Message: 5
Date: Thu, 15 Feb 2018 18:09:11 -0800
From: Semyon Sadetsky <semyon.sadetsky at oracle.com>
To: Krishna Addepalli <krishna.addepalli at oracle.com>,
	awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when
	sequenced events arrive out of sequence
Message-ID: <32533ac8-0007-668f-f691-fab84a8fac84 at oracle.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Hi Krishna,

Unlikely this will work for several app contexts.

You need to find the root cause why the sequenced events get mixed up 
and fix it.

--Semyon


On 02/15/2018 04:16 AM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for ?JDK-8152974: 
> https://bugs.openjdk.java.net/browse/JDK-8152974
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8152974/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8152974/webrev00/>
>
> The problem is when the events arrive out of sequence, the sequenced 
> event?s dispatch loop assumes that the sequenced events are pushed 
> into the queue together, which may not be the case, and this blocks 
> the event queue. The fix is to continue to process all the events, 
> which ultimately leads to the processing of the SequencedEvents in 
> their order of creation.
>
> Thanks,
>
> Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180215/a3b04c00/attachment.html>

End of awt-dev Digest, Vol 130, Issue 11
****************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SequencedEventTest.java
Type: application/octet-stream
Size: 6379 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180216/6bb54aa6/SequencedEventTest-0001.java>

From manajit.halder at oracle.com  Fri Feb 16 09:49:42 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 16 Feb 2018 15:19:42 +0530
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for JDK-7158623:
 [macosx] Should an unfocusable maximized Frame be resizable?
Message-ID: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>

Hi All,

Kindly review the fix for JDK10.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-7158623 <https://bugs.openjdk.java.net/browse/JDK-7158623>

Webrev:
http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ <http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/>

Issue:
Unfocusable frame was resizable.

Fix:
After the fix resizability of the frame depends on focusability of the frame. If the frame is focusable then it is resizable otherwise not.
The test code was cleaned to remove old test machinery code.

Regards,
Manajit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180216/b4c73136/attachment.html>

From manajit.halder at oracle.com  Fri Feb 16 11:48:37 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 16 Feb 2018 17:18:37 +0530
Subject: <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
In-Reply-To: <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
Message-ID: <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>

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/~mhalder/8190767/webrev.02/>

Regards,
Manajit

> On 14-Feb-2018, at 8:29 AM, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.> http://cr.openjdk.java.net/~mhalder/8190767/webrev.01/ <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>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180216/853aa925/attachment.html>

From kevin.rushforth at oracle.com  Fri Feb 16 16:17:26 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 16 Feb 2018 08:17:26 -0800
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for
 JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?
In-Reply-To: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
References: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
Message-ID: <5A870416.1030009@oracle.com>


 > Kindly review the fix for JDK10.

You mean JDK 11, right?

-- Kevin


Manajit Halder wrote:
> Hi All,
>
> Kindly review the fix for JDK10.
>
> Bug: 
> https://bugs.openjdk.java.net/browse/JDK-7158623
>
> Webrev:
> http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ 
> <http://cr.openjdk.java.net/%7Emhalder/7158623/webrev.00/>
>
> Issue:
> Unfocusable frame was resizable.
>
> Fix:
> After the fix resizability of the frame depends on focusability of the 
> frame. If the frame is focusable then it is resizable otherwise not.
> The test code was cleaned to remove old test machinery code.
>
> Regards,
> Manajit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180216/c00c9495/attachment.html>

From philip.race at oracle.com  Fri Feb 16 17:54:18 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Feb 2018 09:54:18 -0800
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for
 JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?
In-Reply-To: <5A870416.1030009@oracle.com>
References: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
 <5A870416.1030009@oracle.com>
Message-ID: <1506b6ce-01db-ddbb-d00f-6647a62c76fc@oracle.com>

webrev appears to be against the correct repo :
sh://hg.openjdk.java.net/jdk/client


First can you point to what in the spec. or whatever points to
the correct desired behaviour being what you describe :
 >If the frame is focusable then it is resizable otherwise not.

And regarding the fix, it isn't obvious how adding RESIZABLE changes 
anything here
for the unfocusable case which seems to be the situation that is under 
discussion.

Before: if its unfocusable, then setStyleBits will set the mask to 0 :

     // this is the counter-point to -[CWindow _nativeSetStyleBit:]
     private void setStyleBits(final int mask, final boolean value) {
         execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? 
mask : 0));
     }

After: .. well exactly the same thing .. you just added a RESIZABLE bit 
that will be ignored.

It may make a difference in the isFocusable case .. but that does not 
match what you
say you are doing.

-phil.

On 02/16/2018 08:17 AM, Kevin Rushforth wrote:
>
> > Kindly review the fix for JDK10.
>
> You mean JDK 11, right?
>
> -- Kevin
>
>
> Manajit Halder wrote:
>> Hi All,
>>
>> Kindly review the fix for JDK10.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-7158623
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Emhalder/7158623/webrev.00/>
>>
>> Issue:
>> Unfocusable frame was resizable.
>>
>> Fix:
>> After the fix resizability of the frame depends on focusability of 
>> the frame. If the frame is focusable then it is resizable otherwise not.
>> The test code was cleaned to remove old test machinery code.
>>
>> Regards,
>> Manajit
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180216/052fa408/attachment.html>

From philip.race at oracle.com  Fri Feb 16 18:15:43 2018
From: philip.race at oracle.com (Phil Race)
Date: Fri, 16 Feb 2018 10:15:43 -0800
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
Message-ID: <ce1043a2-2983-9437-f0a4-691f9e9ca2c5@oracle.com>

Hi,

I'm have no insight into why

-vmoptions:"-Dsun.java2d.uiScale=10"

would not get passed to at least the parent program, but I assume that if we are running on a hidpi setup
there is no need to explicitly pass it to parent or child.

The basic focus of the fix -ensuring we always dispose the frame - seems fine to me.

-phil.

On 02/15/2018 11:33 PM, Jayathirth D V wrote:
> Hi Sergey,
>
> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.
>
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, February 16, 2018 3:28 AM
> To: Jayathirth D V
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting
>
> Hi, Jay.
>> I tried different failure scenarios inside test like making comparing
>> images fail but all the times frames are getting disposed.
>> Could you please elaborate in which scenario exactly you are seeing
>> frame not getting disposed?
> I run the version of the test before your fix, and it leaves one of the frame of the screen.
>
>> But I have still added explicit frame.dispose() at places to make sure
>> that we dispose the created frames.
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>
>> Also in continuation to what we discussed offline, I used
>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command
>> prompt. But in this case also System.getProperty("sun.java2d.uiScale")
>> returned null in test case. So I was not able to pass uiScale
>> mentioned in command prompt to ProcessCommunicator in test case.
> I tested it using this command line:
> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10" -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/  open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
>
> Plus this change in the test:
>      public static void main(String[] arg) throws Exception {
> +       String prop = System.getProperty("sun.java2d.uiScale");
> +	System.err.println(prop);
>
> It prints 10 in the log.
>


From Sergey.Bylokhov at oracle.com  Fri Feb 16 20:06:12 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Feb 2018 12:06:12 -0800
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
Message-ID: <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>

Hi, Jay.
There is one additional small issue, I have found it by run the test on 
win10 where the robot does not work properly(separate bug). The 
subprocess still leaves the frame if the robot did not complete dnd 
properly. I think you can reproduce it by comment out all 
robot.mouseMove operations. The problem is that ImageDropTarget.main() 
did not dispose() the frame at the end of the method(it dispose it only 
in case of some errors). I think that the ImageDropTarget.main() should 
wait some amount of time and then throw an exception/dispose the frame/ 
or something like this. Or maybe the main process should kill/destroy 
the subprocess.


On 15/02/2018 23:33, Jayathirth D V wrote:
> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.
> 
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
> 
> Thanks,
> Jay
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, February 16, 2018 3:28 AM
> To: Jayathirth D V
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting
> 
> Hi, Jay.
>> I tried different failure scenarios inside test like making comparing
>> images fail but all the times frames are getting disposed.
>> Could you please elaborate in which scenario exactly you are seeing
>> frame not getting disposed?
> 
> I run the version of the test before your fix, and it leaves one of the frame of the screen.
> 
>>
>> But I have still added explicit frame.dispose() at places to make sure
>> that we dispose the created frames.
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>
>> Also in continuation to what we discussed offline, I used
>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command
>> prompt. But in this case also System.getProperty("sun.java2d.uiScale")
>> returned null in test case. So I was not able to pass uiScale
>> mentioned in command prompt to ProcessCommunicator in test case.
> 
> I tested it using this command line:
> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10" -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/  open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
> 
> Plus this change in the test:
>      public static void main(String[] arg) throws Exception {
> +       String prop = System.getProperty("sun.java2d.uiScale");
> +	System.err.println(prop);
> 
> It prints 10 in the log.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Feb 16 20:18:53 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Feb 2018 12:18:53 -0800
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
Message-ID: <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>

Hi, Krishna.
On 16/02/2018 00:42, Krishna Addepalli wrote:
> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.

But both events are posted by the test, why the second event is not 
present in the queue?


-- 
Best regards, Sergey.

From krishna.addepalli at oracle.com  Sat Feb 17 02:26:30 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Fri, 16 Feb 2018 18:26:30 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced
	events
In-Reply-To: <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
References: <5359411a-da6a-40bf-8dbb-5bbefb715b14@default>
 <34c68d51-9572-af69-34fd-a614f32d2c22@oracle.com>
Message-ID: <528341f9-53da-4a0c-863f-c4580d7a4db2@default>

Hi Sergey,

The event is present, but with the id "java.awt.event.FocusEvent.FOCUS_LAST+1", whereas when it is pumping the events, it is looking for "java.awt.event.FocusEvent.FOCUS_LAST+2", which is not in the queue.

Thanks,
Krishna

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, February 17, 2018 1:49 AM
To: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net; Semyon Sadetsky <semyon.sadetsky at oracle.com>
Subject: Re: <AWT Dev> [11][JDK-8152974] AWT hang occurs when sequenced events

Hi, Krishna.
On 16/02/2018 00:42, Krishna Addepalli wrote:
> The SentEvent.ID value is "java.awt.event.FocusEvent.FOCUS_LAST+2", and when in the function pumpOneEventForFilters, it tries to call EventQueue.getNextEvent(id), it looks for SentEvent.ID, which is not present, and then the queue blocks in the hope that someone will post that event. This is what is leading to the hang.

But both events are posted by the test, why the second event is not present in the queue?


-- 
Best regards, Sergey.

From prem.balakrishnan at oracle.com  Mon Feb 19 06:03:35 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Sun, 18 Feb 2018 22:03:35 -0800 (PST)
Subject: <AWT Dev> [11] Review Request JDK-8198347 [TESTBUG]
 java/awt/Modal/ToBack/*.java tests fail on Ubuntu 17.10
Message-ID: <9dea0b72-dfe6-4e2f-84ac-d0ad35573a63@default>

Hi All,

 

Please review fix for JDK 11 :

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8198347 

 

Webrev: http://cr.openjdk.java.net/~pkbalakr/8198347/webrev.00/ 

 

Robot mouse move in these tests, placed the mouse cursor exactly on the edge of the Frame/Dialog, 

due to which the cursor changed to resize cursor and mouse press didn't work as expected. 

Proposed fix sets the Frame/Dialog resizable to false. 

These tests fail only on Ubuntu 17.10 .

 

Regards,

Prem

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180218/a51ecd18/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Feb 20 07:08:28 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 19 Feb 2018 23:08:28 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset
 after calling validate()
Message-ID: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>

Hi All, Please review a code fix for the below bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8195738

 

Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

 

Problematic platform: Windows only.

 

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the 

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don't need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

 

Thanks and regards,
Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180219/417f190e/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Feb 20 10:09:46 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 20 Feb 2018 02:09:46 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
Message-ID: <db33aee1-d651-4624-8cf2-16f802ded310@default>

Hi All, Please review a test bug fix for the below bug.

 

               Bug: https://bugs.openjdk.java.net/browse/JDK-8129569

 

               Webrev: http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/

 

Summary: This test was added as part of code fix for the bug: https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one examines the code updates done under this changeset it all relates to the mac platform. Hence this test is updated to run on mac platform only.

 

Thanks and regards,
Shashi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180220/ea23ae0e/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Feb 20 14:36:21 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 06:36:21 -0800
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <db33aee1-d651-4624-8cf2-16f802ded310@default>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
Message-ID: <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>

Hi, Shashi.
Why have you changed the test to othervm?

On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review a test bug fix for the below bug.
> 
>  ?????????????? Bug: https://bugs.openjdk.java.net/browse/JDK-8129569
> 
>  ?????????????? Webrev: 
> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
> 
> Summary: This test was added as part of code fix for the bug: 
> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset: 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one 
> examines the code updates done under this changeset it all relates to 
> the mac platform. Hence this test is updated to run on mac platform only.
> 
> Thanks and regards,
> Shashi
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Feb 20 14:39:44 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 06:39:44 -0800
Subject: <AWT Dev> [11] Review Request JDK-8198347 [TESTBUG]
 java/awt/Modal/ToBack/*.java tests fail on Ubuntu 17.10
In-Reply-To: <9dea0b72-dfe6-4e2f-84ac-d0ad35573a63@default>
References: <9dea0b72-dfe6-4e2f-84ac-d0ad35573a63@default>
Message-ID: <22c7317a-65eb-364f-415b-84649b7127a4@oracle.com>

Hi, Prem.
Can you please clarify is JDK-8196441 duplicate of this bug or not? If 
it is a duplicate then you need to removed these tests from the ProblemList:
java/awt/Modal/ToBack/ToBackAppModal1Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackAppModal2Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackAppModal3Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackAppModal4Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackModal1Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackModal2Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackModal3Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackModal4Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackTKModal1Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackTKModal2Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackTKModal3Test.java 8196441 linux-all
java/awt/Modal/ToBack/ToBackTKModal4Test.java 8196441 linux-all


On 18/02/2018 22:03, Prem Balakrishnan wrote:
> Hi All,
> 
> Please review fix for JDK 11 :
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198347
> 
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8198347/webrev.00/
> 
> Robot mouse move in these tests, placed the mouse cursor exactly on the 
> edge of the Frame/Dialog,
> 
> due to which the cursor changed to resize cursor and mouse press didn?t 
> work as expected.
> 
> Proposed fix sets the Frame/Dialog resizable to false.
> 
> These tests fail only on Ubuntu 17.10 .
> 
> Regards,
> 
> Prem
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Tue Feb 20 14:55:00 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Tue, 20 Feb 2018 20:25:00 +0530
Subject: <AWT Dev> [11] Review Request JDK-8198347 [TESTBUG]
 java/awt/Modal/ToBack/*.java tests fail on Ubuntu 17.10
In-Reply-To: <9dea0b72-dfe6-4e2f-84ac-d0ad35573a63@default>
References: <9dea0b72-dfe6-4e2f-84ac-d0ad35573a63@default>
Message-ID: <e4a0ec82-4aab-7c38-7ee5-62d5c3a70afd@oracle.com>

Hi Prem,

None of this tests fail for me in my ubuntu17.10 even without your fix. 
If I run the toBack folder, I only see the tests mentioned in 
JDK-8196441 to be failing. Maybe you can run in some other 17.10 system.

Regards
Prasanta
On 2/19/2018 11:33 AM, Prem Balakrishnan wrote:
>
> Hi All,
>
> Please review fix for JDK 11 :
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198347
>
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8198347/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8198347/webrev.00/>
>
> Robot mouse move in these tests, placed the mouse cursor exactly on 
> the edge of the Frame/Dialog,
>
> due to which the cursor changed to resize cursor and mouse press 
> didn?t work as expected.
>
> Proposed fix sets the Frame/Dialog resizable to false.
>
> These tests fail only on Ubuntu 17.10 .
>
> Regards,
>
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180220/016f074c/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Feb 20 15:10:14 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 07:10:14 -0800
Subject: <AWT Dev> [11] Review Request: 8198333 ProblemList should be
 updated for headless mode
Message-ID: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>

Hello.
Please review update of the tests for jdk11.

The goal is to make our testing as stable as possible and exclude any 
unstable tests(I have started from the tests which may be run in the 
headless mode).

Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
Webrev can be found at: http://cr.openjdk.java.net/~serb/8198333/webrev.09

  - The ProblemList.txt is update, I have created a list of new bugs for 
any tests which fail at least once in a few iterations on a different 
systems.
  - "@key headful" was added to some tests which are noop in headless 
mode, they have some checks like:
     * Desktop.isDesktopSupported
     * Toolkit.getDefaultToolkit().getClass().getName().equals/
     * GraphicsEnvironment.isHeadlessInstance()
     * SystemTray.isSupported()
    ... etc. These checks are always false in headless mode.
  - "@key printer" was added to the tests which works in the headless 
mode, and tries to print something. Some of these tests are noop w/o 
printer.
  - "@run main/othervm" was added to a few tests which fails in agentvm 
mode. This mode is a default in mach5.
  - A few typos in the tests tags were fixed.

-- 
Best regards, Sergey.

From javalists at cbfiddle.com  Tue Feb 20 15:18:08 2018
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 20 Feb 2018 07:18:08 -0800
Subject: <AWT Dev> [11] Review Request: 8196322: [macosx] When the screen
 menu bar is used, clearing the default menu bar should permit AWT shutdown
Message-ID: <FBC02368-1174-49DC-80BD-E5DC76D7B42E@cbfiddle.com>

Hello,

Please review the following bug fix.

Thank you.

  Alan

Bug: https://bugs.openjdk.java.net/browse/JDK-8196322 <https://bugs.openjdk.java.net/browse/JDK-8196322>
webrev: http://cr.openjdk.java.net/~serb/alans/8196322/webrev.00/ <http://cr.openjdk.java.net/~serb/alans/8196322/webrev.00/>

When a default menu bar is set and the screen menu bar is in use, a heavyweight ScreenMenuBar is created
to manage the connection to the native application menu bar and addNotify() is called to create peers. The
peers are registered and they prevent AWT shutdown from happening.

If the default menu bar is removed, by setting it to null, removeNotify() is not called, so the peers remain
registered and AWT shutdown is still prevented.

The change is to call removeNotify when the current default menu bar is replaced, either by null or a different
menu bar.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180220/8cc64eb5/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Feb 20 17:58:04 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 20 Feb 2018 09:58:04 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
Message-ID: <c280202e-2239-4104-9f82-842c98508f02@default>

Hi Sergey, The only reason I thought was to use a separate JVM though in this case it is not required as I am not setting any specific settings for this JVM.

But in general, isn't the othervm is preferable?

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, February 20, 2018 8:06 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails

Hi, Shashi.
Why have you changed the test to othervm?

On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review a test bug fix for the below bug.
> 
>  ?????????????? Bug: https://bugs.openjdk.java.net/browse/JDK-8129569
> 
>  ?????????????? Webrev: 
> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
> 
> Summary: This test was added as part of code fix for the bug: 
> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset: 
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one 
> examines the code updates done under this changeset it all relates to 
> the mac platform. Hence this test is updated to run on mac platform only.
> 
> Thanks and regards,
> Shashi
> 


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Feb 20 19:23:50 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 11:23:50 -0800
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <c280202e-2239-4104-9f82-842c98508f02@default>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
 <c280202e-2239-4104-9f82-842c98508f02@default>
Message-ID: <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>

On 20/02/2018 09:58, Shashidhara Veerabhadraiah wrote:
> But in general, isn't the othervm is preferable?

If it is not critical for the test it is better to use a default mode, 
which maybe an agentvm(this mode can be faster than othervm).

> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, February 20, 2018 8:06 PM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
> 
> Hi, Shashi.
> Why have you changed the test to othervm?
> 
> On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a test bug fix for the below bug.
>>
>>   ?????????????? Bug: https://bugs.openjdk.java.net/browse/JDK-8129569
>>
>>   ?????????????? Webrev:
>> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
>>
>> Summary: This test was added as part of code fix for the bug:
>> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset:
>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one
>> examines the code updates done under this changeset it all relates to
>> the mac platform. Hence this test is updated to run on mac platform only.
>>
>> Thanks and regards,
>> Shashi
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Feb 20 19:31:20 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 11:31:20 -0800
Subject: <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
In-Reply-To: <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
Message-ID: <5bbff4bf-177a-eb20-d50c-8e6315befd7f@oracle.com>

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.
> 


-- 
Best regards, Sergey.

From kevin.rushforth at oracle.com  Tue Feb 20 19:35:16 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Feb 2018 11:35:16 -0800
Subject: <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
In-Reply-To: <5bbff4bf-177a-eb20-d50c-8e6315befd7f@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5bbff4bf-177a-eb20-d50c-8e6315befd7f@oracle.com>
Message-ID: <5A8C7874.4060709@oracle.com>

The new code is already inside an "if (target instanceof Frame)" check...

-- 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.
>>
>
>

From Sergey.Bylokhov at oracle.com  Tue Feb 20 19:52:07 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 11:52:07 -0800
Subject: <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
In-Reply-To: <5A8C7874.4060709@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5bbff4bf-177a-eb20-d50c-8e6315befd7f@oracle.com>
 <5A8C7874.4060709@oracle.com>
Message-ID: <c9030de7-8377-6c8e-184e-a0549243cd21@oracle.com>

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.
>>>
>>
>>


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 20 20:03:22 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Feb 2018 12:03:22 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
Message-ID: <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>

+1

-phil

On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
> Hello.
> Please review update of the tests for jdk11.
>
> The goal is to make our testing as stable as possible and exclude any 
> unstable tests(I have started from the tests which may be run in the 
> headless mode).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>
>  - The ProblemList.txt is update, I have created a list of new bugs 
> for any tests which fail at least once in a few iterations on a 
> different systems.
>  - "@key headful" was added to some tests which are noop in headless 
> mode, they have some checks like:
>     * Desktop.isDesktopSupported
>     * Toolkit.getDefaultToolkit().getClass().getName().equals/
>     * GraphicsEnvironment.isHeadlessInstance()
>     * SystemTray.isSupported()
>    ... etc. These checks are always false in headless mode.
>  - "@key printer" was added to the tests which works in the headless 
> mode, and tries to print something. Some of these tests are noop w/o 
> printer.
>  - "@run main/othervm" was added to a few tests which fails in agentvm 
> mode. This mode is a default in mach5.
>  - A few typos in the tests tags were fixed.
>


From kevin.rushforth at oracle.com  Tue Feb 20 20:16:28 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Feb 2018 12:16:28 -0800
Subject: <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
In-Reply-To: <c9030de7-8377-6c8e-184e-a0549243cd21@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5bbff4bf-177a-eb20-d50c-8e6315befd7f@oracle.com>
 <5A8C7874.4060709@oracle.com>
 <c9030de7-8377-6c8e-184e-a0549243cd21@oracle.com>
Message-ID: <5A8C821C.7000401@oracle.com>

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.
>>>>
>>>
>>>
>
>

From philip.race at oracle.com  Tue Feb 20 20:20:44 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Feb 2018 12:20:44 -0800
Subject: <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
In-Reply-To: <5A8C821C.7000401@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5bbff4bf-177a-eb20-d50c-8e6315befd7f@oracle.com>
 <5A8C7874.4060709@oracle.com>
 <c9030de7-8377-6c8e-184e-a0549243cd21@oracle.com>
 <5A8C821C.7000401@oracle.com>
Message-ID: <ad049bc0-f4b8-566f-a686-85610a2ba4a7@oracle.com>

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.
>>>>>
>>>>
>>>>
>>
>>


From philip.race at oracle.com  Tue Feb 20 20:55:34 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Feb 2018 12:55:34 -0800
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
 <c280202e-2239-4104-9f82-842c98508f02@default>
 <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>
Message-ID: <c7de19ed-ba2f-5f10-a530-1f80d18c6a32@oracle.com>

If jtreg ran all tests ran in othervm mode it would likely take much 
longer .. which
is a big reason why the default is agentvm and not othervm.
If the test destabilises the VM or is a resource hog, or needs VM 
special settings (eg setting a system property)
then othervm would be the way to go.

-phil.


On 02/20/2018 11:23 AM, Sergey Bylokhov wrote:
> On 20/02/2018 09:58, Shashidhara Veerabhadraiah wrote:
>> But in general, isn't the othervm is preferable?
>
> If it is not critical for the test it is better to use a default mode, 
> which maybe an agentvm(this mode can be faster than othervm).
>
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 20, 2018 8:06 PM
>> To: Shashidhara Veerabhadraiah 
>> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: [11] JDK-8129569: [TEST_BUG] Test 
>> java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
>>
>> Hi, Shashi.
>> Why have you changed the test to othervm?
>>
>> On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test bug fix for the below bug.
>>>
>>>                  Bug: https://bugs.openjdk.java.net/browse/JDK-8129569
>>>
>>>                  Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
>>>
>>> Summary: This test was added as part of code fix for the bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one
>>> examines the code updates done under this changeset it all relates to
>>> the mac platform. Hence this test is updated to run on mac platform 
>>> only.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>
>
>


From shashidhara.veerabhadraiah at oracle.com  Wed Feb 21 03:52:03 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 20 Feb 2018 19:52:03 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <c7de19ed-ba2f-5f10-a530-1f80d18c6a32@oracle.com>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
 <c280202e-2239-4104-9f82-842c98508f02@default>
 <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>
 <c7de19ed-ba2f-5f10-a530-1f80d18c6a32@oracle.com>
Message-ID: <6702d8d6-b2cc-4fac-b8ba-605cc4a1a4f8@default>

Thank you Phil and Sergey for the clarification.

Thanks and regards,
Shashi

-----Original Message-----
From: Phil Race 
Sent: Wednesday, February 21, 2018 2:26 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails

If jtreg ran all tests ran in othervm mode it would likely take much longer .. which is a big reason why the default is agentvm and not othervm.
If the test destabilises the VM or is a resource hog, or needs VM special settings (eg setting a system property) then othervm would be the way to go.

-phil.


On 02/20/2018 11:23 AM, Sergey Bylokhov wrote:
> On 20/02/2018 09:58, Shashidhara Veerabhadraiah wrote:
>> But in general, isn't the othervm is preferable?
>
> If it is not critical for the test it is better to use a default mode, 
> which maybe an agentvm(this mode can be faster than othervm).
>
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 20, 2018 8:06 PM
>> To: Shashidhara Veerabhadraiah
>> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: [11] JDK-8129569: [TEST_BUG] Test 
>> java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java 
>> fails
>>
>> Hi, Shashi.
>> Why have you changed the test to othervm?
>>
>> On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test bug fix for the below bug.
>>>
>>>                  Bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-8129569
>>>
>>>                  Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
>>>
>>> Summary: This test was added as part of code fix for the bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one 
>>> examines the code updates done under this changeset it all relates 
>>> to the mac platform. Hence this test is updated to run on mac 
>>> platform only.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>
>


From prem.balakrishnan at oracle.com  Wed Feb 21 04:07:46 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Tue, 20 Feb 2018 20:07:46 -0800 (PST)
Subject: <AWT Dev> [11] Review Request JDK-8198347 [TESTBUG]
 java/awt/Modal/ToBack/*.java tests fail on Ubuntu 17.10
In-Reply-To: <22c7317a-65eb-364f-415b-84649b7127a4@oracle.com>
References: <9dea0b72-dfe6-4e2f-84ac-d0ad35573a63@default>
 <22c7317a-65eb-364f-415b-84649b7127a4@oracle.com>
Message-ID: <4adebf9f-5722-4492-a908-5204d3ee619c@default>

Hi Sergey,

Patch which I have submitted is for different issue(different tests), which fails only on Ubuntu 17.10. 
JDK-8196441 is NOT duplicate of JDK-8198347.

-Prem

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, February 20, 2018 8:10 PM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request JDK-8198347 [TESTBUG] java/awt/Modal/ToBack/*.java tests fail on Ubuntu 17.10

Hi, Prem.
Can you please clarify is JDK-8196441 duplicate of this bug or not? If it is a duplicate then you need to removed these tests from the ProblemList:
java/awt/Modal/ToBack/ToBackAppModal1Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackAppModal2Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackAppModal3Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackAppModal4Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackModal1Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackModal2Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackModal3Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackModal4Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackTKModal1Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackTKModal2Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackTKModal3Test.java 8196441 linux-all java/awt/Modal/ToBack/ToBackTKModal4Test.java 8196441 linux-all


On 18/02/2018 22:03, Prem Balakrishnan wrote:
> Hi All,
> 
> Please review fix for JDK 11 :
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198347
> 
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8198347/webrev.00/
> 
> Robot mouse move in these tests, placed the mouse cursor exactly on the 
> edge of the Frame/Dialog,
> 
> due to which the cursor changed to resize cursor and mouse press didn't 
> work as expected.
> 
> Proposed fix sets the Frame/Dialog resizable to false.
> 
> These tests fail only on Ubuntu 17.10 .
> 
> Regards,
> 
> Prem
> 


-- 
Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Wed Feb 21 04:23:03 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 20 Feb 2018 20:23:03 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <6702d8d6-b2cc-4fac-b8ba-605cc4a1a4f8@default>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
 <c280202e-2239-4104-9f82-842c98508f02@default>
 <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>
 <c7de19ed-ba2f-5f10-a530-1f80d18c6a32@oracle.com>
 <6702d8d6-b2cc-4fac-b8ba-605cc4a1a4f8@default>
Message-ID: <1e322c7a-166b-4bb4-939a-190e8b66a481@default>

Hi, Please find the updated webrev per the comments:
http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.01/

Thanks and regards,
Shashi

-----Original Message-----
From: Shashidhara Veerabhadraiah 
Sent: Wednesday, February 21, 2018 9:22 AM
To: Philip Race <philip.race at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails

Thank you Phil and Sergey for the clarification.

Thanks and regards,
Shashi

-----Original Message-----
From: Phil Race
Sent: Wednesday, February 21, 2018 2:26 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails

If jtreg ran all tests ran in othervm mode it would likely take much longer .. which is a big reason why the default is agentvm and not othervm.
If the test destabilises the VM or is a resource hog, or needs VM special settings (eg setting a system property) then othervm would be the way to go.

-phil.


On 02/20/2018 11:23 AM, Sergey Bylokhov wrote:
> On 20/02/2018 09:58, Shashidhara Veerabhadraiah wrote:
>> But in general, isn't the othervm is preferable?
>
> If it is not critical for the test it is better to use a default mode, 
> which maybe an agentvm(this mode can be faster than othervm).
>
>>
>> Thanks and regards,
>> Shashi
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 20, 2018 8:06 PM
>> To: Shashidhara Veerabhadraiah
>> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: [11] JDK-8129569: [TEST_BUG] Test 
>> java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java
>> fails
>>
>> Hi, Shashi.
>> Why have you changed the test to othervm?
>>
>> On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test bug fix for the below bug.
>>>
>>>                  Bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-8129569
>>>
>>>                  Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
>>>
>>> Summary: This test was added as part of code fix for the bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one 
>>> examines the code updates done under this changeset it all relates 
>>> to the mac platform. Hence this test is updated to run on mac 
>>> platform only.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>
>


From jayathirth.d.v at oracle.com  Wed Feb 21 08:55:01 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 21 Feb 2018 00:55:01 -0800 (PST)
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
 <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>
Message-ID: <f59e6637-8f07-43be-aab6-11003815d4d0@default>

Hi Sergey,

Thanks for your inputs.
I changed robot.mouseMouse() parameters and observed that if we don?t receive any updates in ImageDropTarget listener we will not dispose ImageDropTarget frame.
I tried using ProcessCommunicator.destroyProcess() in finally block of ImageDragSource but it also didn?t dispose the ImageDropTarget frame.

So as suggested I have added 2 min wait in ImageDropTarget.main() and if we don?t receive anything in ImageDropTarget listener we will dispose() the frame. Usually in my machine it takes around 25seconds for DnD of all image formats so 2 minutes wait should be more than enough in all machines and different HiDPI scenarios.

Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8197926/webrev.03/ 

Thanks,
Jay 

-----Original Message-----
From: Sergey Bylokhov 
Sent: Saturday, February 17, 2018 1:36 AM
To: Jayathirth D V
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting

Hi, Jay.
There is one additional small issue, I have found it by run the test on
win10 where the robot does not work properly(separate bug). The subprocess still leaves the frame if the robot did not complete dnd properly. I think you can reproduce it by comment out all robot.mouseMove operations. The problem is that ImageDropTarget.main() did not dispose() the frame at the end of the method(it dispose it only in case of some errors). I think that the ImageDropTarget.main() should wait some amount of time and then throw an exception/dispose the frame/ or something like this. Or maybe the main process should kill/destroy the subprocess.


On 15/02/2018 23:33, Jayathirth D V wrote:
> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.
> 
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
> 
> Thanks,
> Jay
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Friday, February 16, 2018 3:28 AM
> To: Jayathirth D V
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: 
> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the 
> windows in HiDPI setting
> 
> Hi, Jay.
>> I tried different failure scenarios inside test like making comparing 
>> images fail but all the times frames are getting disposed.
>> Could you please elaborate in which scenario exactly you are seeing 
>> frame not getting disposed?
> 
> I run the version of the test before your fix, and it leaves one of the frame of the screen.
> 
>>
>> But I have still added explicit frame.dispose() at places to make 
>> sure that we dispose the created frames.
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>
>> Also in continuation to what we discussed offline, I used 
>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command 
>> prompt. But in this case also 
>> System.getProperty("sun.java2d.uiScale")
>> returned null in test case. So I was not able to pass uiScale 
>> mentioned in command prompt to ProcessCommunicator in test case.
> 
> I tested it using this command line:
> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10" 
> -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/  
> open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
> 
> Plus this change in the test:
>      public static void main(String[] arg) throws Exception {
> +       String prop = System.getProperty("sun.java2d.uiScale");
> +	System.err.println(prop);
> 
> It prints 10 in the log.
> 


--
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Feb 21 13:58:02 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Feb 2018 19:28:02 +0530
Subject: <AWT Dev> [OpenJDK 2D-Dev] [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
Message-ID: <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>

Couple of points.

Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be run 
only on solaris/linux as it tests

if (!isXAWT){
   77             System.out.println(" this is XAWT-only test. ");
   78             return;
   79         }

java/awt/Toolkit/RealSync/Test.java has
System.exit(1);

Should we not remove that as it might hamper jtreg run?

I also think that this bugid needs to be added to all updated tests.

Regards
Prasanta

On 2/21/2018 1:33 AM, Phil Race wrote:
> +1
>
> -phil
>
> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review update of the tests for jdk11.
>>
>> The goal is to make our testing as stable as possible and exclude any 
>> unstable tests(I have started from the tests which may be run in the 
>> headless mode).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>
>> ?- The ProblemList.txt is update, I have created a list of new bugs 
>> for any tests which fail at least once in a few iterations on a 
>> different systems.
>> ?- "@key headful" was added to some tests which are noop in headless 
>> mode, they have some checks like:
>> ??? * Desktop.isDesktopSupported
>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>> ??? * GraphicsEnvironment.isHeadlessInstance()
>> ??? * SystemTray.isSupported()
>> ?? ... etc. These checks are always false in headless mode.
>> ?- "@key printer" was added to the tests which works in the headless 
>> mode, and tries to print something. Some of these tests are noop w/o 
>> printer.
>> ?- "@run main/othervm" was added to a few tests which fails in 
>> agentvm mode. This mode is a default in mach5.
>> ?- A few typos in the tests tags were fixed.
>>
>


From prasanta.sadhukhan at oracle.com  Wed Feb 21 15:03:51 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Feb 2018 20:33:51 +0530
Subject: <AWT Dev> <Swing Dev> [OpenJDK 2D-Dev] [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
Message-ID: <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>

Also, these test should have @requires os.family too

/java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only

if (!osName.startsWith("mac")) {
   42             return;
   43         }

javax/print/PrintServiceLookup/CountPrintServices.java for linux only
if (!os.equals("linux")) {
   44         System.out.println("Linux specific test. No need to continue");
   45         return;
   46     }

Regards
Prasanta

On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
> Couple of points.
>
> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
> run only on solaris/linux as it tests
>
> if (!isXAWT){
> ? 77???????????? System.out.println(" this is XAWT-only test. ");
> ? 78???????????? return;
> ? 79???????? }
>
> java/awt/Toolkit/RealSync/Test.java has
> System.exit(1);
>
> Should we not remove that as it might hamper jtreg run?
>
> I also think that this bugid needs to be added to all updated tests.
>
> Regards
> Prasanta
>
> On 2/21/2018 1:33 AM, Phil Race wrote:
>> +1
>>
>> -phil
>>
>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review update of the tests for jdk11.
>>>
>>> The goal is to make our testing as stable as possible and exclude 
>>> any unstable tests(I have started from the tests which may be run in 
>>> the headless mode).
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>
>>> ?- The ProblemList.txt is update, I have created a list of new bugs 
>>> for any tests which fail at least once in a few iterations on a 
>>> different systems.
>>> ?- "@key headful" was added to some tests which are noop in headless 
>>> mode, they have some checks like:
>>> ??? * Desktop.isDesktopSupported
>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>> ??? * SystemTray.isSupported()
>>> ?? ... etc. These checks are always false in headless mode.
>>> ?- "@key printer" was added to the tests which works in the headless 
>>> mode, and tries to print something. Some of these tests are noop w/o 
>>> printer.
>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>> agentvm mode. This mode is a default in mach5.
>>> ?- A few typos in the tests tags were fixed.
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Wed Feb 21 15:45:44 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 07:45:44 -0800
Subject: <AWT Dev> <Swing Dev> [OpenJDK 2D-Dev] [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
Message-ID: <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>

Hi, Prasanta.
I have updated the tests mentioned in your previous email:
http://cr.openjdk.java.net/~serb/8198333/webrev.10

> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
> 
> if (!osName.startsWith("mac")) {
>  ? 42???????????? return;
>  ? 43???????? }

I am not sure it has mac specific code, I'll reevaluate this test in 
JDK-8198406.


> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
> if (!os.equals("linux")) {
>  ? 44???????? System.out.println("Linux specific test. No need to 
> continue");
>  ? 45???????? return;
>  ? 46???? }

I guess this one could be run on mac as well, but it should be double 
checked.

Both tests have headful or printer keywords and already excluded in the 
headless mode, which is subject of the fix.

> 
> Regards
> Prasanta
> 
> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>> Couple of points.
>>
>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>> run only on solaris/linux as it tests
>>
>> if (!isXAWT){
>> ? 77???????????? System.out.println(" this is XAWT-only test. ");
>> ? 78???????????? return;
>> ? 79???????? }
>>
>> java/awt/Toolkit/RealSync/Test.java has
>> System.exit(1);
>>
>> Should we not remove that as it might hamper jtreg run?
>>
>> I also think that this bugid needs to be added to all updated tests.
>>
>> Regards
>> Prasanta
>>
>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>> +1
>>>
>>> -phil
>>>
>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review update of the tests for jdk11.
>>>>
>>>> The goal is to make our testing as stable as possible and exclude 
>>>> any unstable tests(I have started from the tests which may be run in 
>>>> the headless mode).
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>
>>>> ?- The ProblemList.txt is update, I have created a list of new bugs 
>>>> for any tests which fail at least once in a few iterations on a 
>>>> different systems.
>>>> ?- "@key headful" was added to some tests which are noop in headless 
>>>> mode, they have some checks like:
>>>> ??? * Desktop.isDesktopSupported
>>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>>> ??? * SystemTray.isSupported()
>>>> ?? ... etc. These checks are always false in headless mode.
>>>> ?- "@key printer" was added to the tests which works in the headless 
>>>> mode, and tries to print something. Some of these tests are noop w/o 
>>>> printer.
>>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>>> agentvm mode. This mode is a default in mach5.
>>>> ?- A few typos in the tests tags were fixed.
>>>>
>>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Feb 21 15:51:43 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 07:51:43 -0800
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <f59e6637-8f07-43be-aab6-11003815d4d0@default>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
 <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>
 <f59e6637-8f07-43be-aab6-11003815d4d0@default>
Message-ID: <c40a8817-9f04-6dd7-03c7-c52383433e2c@oracle.com>

Hi, Jay.
It looks like some synchronization is required when you access 
"dropCount" from two threads(the drop callback and the new added Thread).

On 21/02/2018 00:55, Jayathirth D V wrote:
> Hi Sergey,
> 
> Thanks for your inputs.
> I changed robot.mouseMouse() parameters and observed that if we don?t receive any updates in ImageDropTarget listener we will not dispose ImageDropTarget frame.
> I tried using ProcessCommunicator.destroyProcess() in finally block of ImageDragSource but it also didn?t dispose the ImageDropTarget frame.
> 
> So as suggested I have added 2 min wait in ImageDropTarget.main() and if we don?t receive anything in ImageDropTarget listener we will dispose() the frame. Usually in my machine it takes around 25seconds for DnD of all image formats so 2 minutes wait should be more than enough in all machines and different HiDPI scenarios.
> 
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.03/
> 
> Thanks,
> Jay
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 17, 2018 1:36 AM
> To: Jayathirth D V
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting
> 
> Hi, Jay.
> There is one additional small issue, I have found it by run the test on
> win10 where the robot does not work properly(separate bug). The subprocess still leaves the frame if the robot did not complete dnd properly. I think you can reproduce it by comment out all robot.mouseMove operations. The problem is that ImageDropTarget.main() did not dispose() the frame at the end of the method(it dispose it only in case of some errors). I think that the ImageDropTarget.main() should wait some amount of time and then throw an exception/dispose the frame/ or something like this. Or maybe the main process should kill/destroy the subprocess.
> 
> 
> On 15/02/2018 23:33, Jayathirth D V wrote:
>> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.
>>
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
>>
>> Thanks,
>> Jay
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Friday, February 16, 2018 3:28 AM
>> To: Jayathirth D V
>> Cc: awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
>> windows in HiDPI setting
>>
>> Hi, Jay.
>>> I tried different failure scenarios inside test like making comparing
>>> images fail but all the times frames are getting disposed.
>>> Could you please elaborate in which scenario exactly you are seeing
>>> frame not getting disposed?
>>
>> I run the version of the test before your fix, and it leaves one of the frame of the screen.
>>
>>>
>>> But I have still added explicit frame.dispose() at places to make
>>> sure that we dispose the created frames.
>>> Please find updated webrev for review:
>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>>
>>> Also in continuation to what we discussed offline, I used
>>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command
>>> prompt. But in this case also
>>> System.getProperty("sun.java2d.uiScale")
>>> returned null in test case. So I was not able to pass uiScale
>>> mentioned in command prompt to ProcessCommunicator in test case.
>>
>> I tested it using this command line:
>> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10"
>> -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/
>> open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
>>
>> Plus this change in the test:
>>       public static void main(String[] arg) throws Exception {
>> +       String prop = System.getProperty("sun.java2d.uiScale");
>> +	System.err.println(prop);
>>
>> It prints 10 in the log.
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Feb 21 15:49:17 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Feb 2018 21:19:17 +0530
Subject: <AWT Dev> <Swing Dev> [OpenJDK 2D-Dev] [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
Message-ID: <e7df679e-abd2-7ef1-e5b3-7df66eadfd4c@oracle.com>

looks ok. Only thing is the tests do not have the current bugid appended.

Regards
Prasanta
On 2/21/2018 9:15 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> I have updated the tests mentioned in your previous email:
> http://cr.openjdk.java.net/~serb/8198333/webrev.10
>
>> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
>>
>> if (!osName.startsWith("mac")) {
>> ?? 42???????????? return;
>> ?? 43???????? }
>
> I am not sure it has mac specific code, I'll reevaluate this test in 
> JDK-8198406.
>
>
>> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
>> if (!os.equals("linux")) {
>> ?? 44???????? System.out.println("Linux specific test. No need to 
>> continue");
>> ?? 45???????? return;
>> ?? 46???? }
>
> I guess this one could be run on mac as well, but it should be double 
> checked.
>
> Both tests have headful or printer keywords and already excluded in 
> the headless mode, which is subject of the fix.
>
>>
>> Regards
>> Prasanta
>>
>> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>>> Couple of points.
>>>
>>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>>> run only on solaris/linux as it tests
>>>
>>> if (!isXAWT){
>>> ? 77???????????? System.out.println(" this is XAWT-only test. ");
>>> ? 78???????????? return;
>>> ? 79???????? }
>>>
>>> java/awt/Toolkit/RealSync/Test.java has
>>> System.exit(1);
>>>
>>> Should we not remove that as it might hamper jtreg run?
>>>
>>> I also think that this bugid needs to be added to all updated tests.
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>>> +1
>>>>
>>>> -phil
>>>>
>>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review update of the tests for jdk11.
>>>>>
>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>> any unstable tests(I have started from the tests which may be run 
>>>>> in the headless mode).
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>>
>>>>> ?- The ProblemList.txt is update, I have created a list of new 
>>>>> bugs for any tests which fail at least once in a few iterations on 
>>>>> a different systems.
>>>>> ?- "@key headful" was added to some tests which are noop in 
>>>>> headless mode, they have some checks like:
>>>>> ??? * Desktop.isDesktopSupported
>>>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>>>> ??? * SystemTray.isSupported()
>>>>> ?? ... etc. These checks are always false in headless mode.
>>>>> ?- "@key printer" was added to the tests which works in the 
>>>>> headless mode, and tries to print something. Some of these tests 
>>>>> are noop w/o printer.
>>>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>>>> agentvm mode. This mode is a default in mach5.
>>>>> ?- A few typos in the tests tags were fixed.
>>>>>
>>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Feb 21 16:04:44 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 08:04:44 -0800
Subject: <AWT Dev> <Swing Dev> [OpenJDK 2D-Dev] [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <e7df679e-abd2-7ef1-e5b3-7df66eadfd4c@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
 <e7df679e-abd2-7ef1-e5b3-7df66eadfd4c@oracle.com>
Message-ID: <f9d47afa-dddd-4f82-872e-9212cd21de06@oracle.com>

I am not sure that it is useful to add a bugid when the test is moved or 
some tags are updated or some small bugs fixed in the test.

The @bug tag contains a bugid for which it was written or an bugid which 
was found by this test later.
It can contain the bugid of bugfix in the test if the fix will rewrite 
the test completely or add some new steps to check(But it likely will be 
an RFE)

On 21/02/2018 07:49, Prasanta Sadhukhan wrote:
> looks ok. Only thing is the tests do not have the current bugid appended.
> 
> Regards
> Prasanta
> On 2/21/2018 9:15 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> I have updated the tests mentioned in your previous email:
>> http://cr.openjdk.java.net/~serb/8198333/webrev.10
>>
>>> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
>>>
>>> if (!osName.startsWith("mac")) {
>>> ?? 42???????????? return;
>>> ?? 43???????? }
>>
>> I am not sure it has mac specific code, I'll reevaluate this test in 
>> JDK-8198406.
>>
>>
>>> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
>>> if (!os.equals("linux")) {
>>> ?? 44???????? System.out.println("Linux specific test. No need to 
>>> continue");
>>> ?? 45???????? return;
>>> ?? 46???? }
>>
>> I guess this one could be run on mac as well, but it should be double 
>> checked.
>>
>> Both tests have headful or printer keywords and already excluded in 
>> the headless mode, which is subject of the fix.
>>
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>>>> Couple of points.
>>>>
>>>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>>>> run only on solaris/linux as it tests
>>>>
>>>> if (!isXAWT){
>>>> ? 77???????????? System.out.println(" this is XAWT-only test. ");
>>>> ? 78???????????? return;
>>>> ? 79???????? }
>>>>
>>>> java/awt/Toolkit/RealSync/Test.java has
>>>> System.exit(1);
>>>>
>>>> Should we not remove that as it might hamper jtreg run?
>>>>
>>>> I also think that this bugid needs to be added to all updated tests.
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>>>> +1
>>>>>
>>>>> -phil
>>>>>
>>>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review update of the tests for jdk11.
>>>>>>
>>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>>> any unstable tests(I have started from the tests which may be run 
>>>>>> in the headless mode).
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>>>> Webrev can be found at: 
>>>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>>>
>>>>>> ?- The ProblemList.txt is update, I have created a list of new 
>>>>>> bugs for any tests which fail at least once in a few iterations on 
>>>>>> a different systems.
>>>>>> ?- "@key headful" was added to some tests which are noop in 
>>>>>> headless mode, they have some checks like:
>>>>>> ??? * Desktop.isDesktopSupported
>>>>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>>>>> ??? * SystemTray.isSupported()
>>>>>> ?? ... etc. These checks are always false in headless mode.
>>>>>> ?- "@key printer" was added to the tests which works in the 
>>>>>> headless mode, and tries to print something. Some of these tests 
>>>>>> are noop w/o printer.
>>>>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>>>>> agentvm mode. This mode is a default in mach5.
>>>>>> ?- A few typos in the tests tags were fixed.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Feb 21 16:05:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 08:05:41 -0800
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <1e322c7a-166b-4bb4-939a-190e8b66a481@default>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
 <c280202e-2239-4104-9f82-842c98508f02@default>
 <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>
 <c7de19ed-ba2f-5f10-a530-1f80d18c6a32@oracle.com>
 <6702d8d6-b2cc-4fac-b8ba-605cc4a1a4f8@default>
 <1e322c7a-166b-4bb4-939a-190e8b66a481@default>
Message-ID: <da555743-0c34-4f83-6dfd-2d9988930b22@oracle.com>

Looks fine.

On 20/02/2018 20:23, Shashidhara Veerabhadraiah wrote:
> Hi, Please find the updated webrev per the comments:
> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.01/
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Shashidhara Veerabhadraiah
> Sent: Wednesday, February 21, 2018 9:22 AM
> To: Philip Race <philip.race at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
> 
> Thank you Phil and Sergey for the clarification.
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Phil Race
> Sent: Wednesday, February 21, 2018 2:26 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
> 
> If jtreg ran all tests ran in othervm mode it would likely take much longer .. which is a big reason why the default is agentvm and not othervm.
> If the test destabilises the VM or is a resource hog, or needs VM special settings (eg setting a system property) then othervm would be the way to go.
> 
> -phil.
> 
> 
> On 02/20/2018 11:23 AM, Sergey Bylokhov wrote:
>> On 20/02/2018 09:58, Shashidhara Veerabhadraiah wrote:
>>> But in general, isn't the othervm is preferable?
>>
>> If it is not critical for the test it is better to use a default mode,
>> which maybe an agentvm(this mode can be faster than othervm).
>>
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Tuesday, February 20, 2018 8:06 PM
>>> To: Shashidhara Veerabhadraiah
>>> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
>>> Subject: Re: [11] JDK-8129569: [TEST_BUG] Test
>>> java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java
>>> fails
>>>
>>> Hi, Shashi.
>>> Why have you changed the test to othervm?
>>>
>>> On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
>>>> Hi All, Please review a test bug fix for the below bug.
>>>>
>>>>                   Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8129569
>>>>
>>>>                   Webrev:
>>>> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
>>>>
>>>> Summary: This test was added as part of code fix for the bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset:
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one
>>>> examines the code updates done under this changeset it all relates
>>>> to the mac platform. Hence this test is updated to run on mac
>>>> platform only.
>>>>
>>>> Thanks and regards,
>>>> Shashi
>>>>
>>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Feb 21 16:49:39 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 21 Feb 2018 08:49:39 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
Message-ID: <5A8DA323.5000907@oracle.com>



On 2/21/18, 7:45 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> I have updated the tests mentioned in your previous email:
> http://cr.openjdk.java.net/~serb/8198333/webrev.10
>
>> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
>>
>> if (!osName.startsWith("mac")) {
>>    42             return;
>>    43         }
>
> I am not sure it has mac specific code, I'll reevaluate this test in 
> JDK-8198406.

This is mac-specific. It looks for specific fonts by name that exist 
only on MacOS.
And moreover the table handling in the implementation is relevant only 
for Apple AAT fonts ..
which you won't find anywhere else.
The one thing about this test that could change is that it doesn't need 
to create a Frame to
test this code -  drawing to a BI would suffice .. so it does not have 
to be headful with a few changes.

-phil.
>
>
>> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
>> if (!os.equals("linux")) {
>>    44         System.out.println("Linux specific test. No need to 
>> continue");
>>    45         return;
>>    46     }
>
> I guess this one could be run on mac as well, but it should be double 
> checked.
>
> Both tests have headful or printer keywords and already excluded in 
> the headless mode, which is subject of the fix.
>
>>
>> Regards
>> Prasanta
>>
>> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>>> Couple of points.
>>>
>>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>>> run only on solaris/linux as it tests
>>>
>>> if (!isXAWT){
>>>   77             System.out.println(" this is XAWT-only test. ");
>>>   78             return;
>>>   79         }
>>>
>>> java/awt/Toolkit/RealSync/Test.java has
>>> System.exit(1);
>>>
>>> Should we not remove that as it might hamper jtreg run?
>>>
>>> I also think that this bugid needs to be added to all updated tests.
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>>> +1
>>>>
>>>> -phil
>>>>
>>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review update of the tests for jdk11.
>>>>>
>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>> any unstable tests(I have started from the tests which may be run 
>>>>> in the headless mode).
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>>
>>>>>  - The ProblemList.txt is update, I have created a list of new 
>>>>> bugs for any tests which fail at least once in a few iterations on 
>>>>> a different systems.
>>>>>  - "@key headful" was added to some tests which are noop in 
>>>>> headless mode, they have some checks like:
>>>>>     * Desktop.isDesktopSupported
>>>>>     * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>>>     * GraphicsEnvironment.isHeadlessInstance()
>>>>>     * SystemTray.isSupported()
>>>>>    ... etc. These checks are always false in headless mode.
>>>>>  - "@key printer" was added to the tests which works in the 
>>>>> headless mode, and tries to print something. Some of these tests 
>>>>> are noop w/o printer.
>>>>>  - "@run main/othervm" was added to a few tests which fails in 
>>>>> agentvm mode. This mode is a default in mach5.
>>>>>  - A few typos in the tests tags were fixed.
>>>>>
>>>>
>>>
>>
>
>

From Sergey.Bylokhov at oracle.com  Wed Feb 21 17:34:04 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 09:34:04 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <5A8DA323.5000907@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
 <5A8DA323.5000907@oracle.com>
Message-ID: <41e5a424-9cb3-95f9-9c29-9139fd8adfbc@oracle.com>

On 21/02/2018 08:49, Philip Race wrote:
>> I am not sure it has mac specific code, I'll reevaluate this test in 
>> JDK-8198406.
> 
> This is mac-specific. It looks for specific fonts by name that exist 
> only on MacOS.
> And moreover the table handling in the implementation is relevant only 
> for Apple AAT fonts ..
> which you won't find anywhere else.
> The one thing about this test that could change is that it doesn't need 
> to create a Frame to
> test this code -? drawing to a BI would suffice .. so it does not have 
> to be headful with a few changes.

I would not like to mix the test changes and updating the problem list. 
I have filed a separate bugs for each test which should be 
updated/reworked/fixed.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Feb 21 17:35:36 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 21 Feb 2018 09:35:36 -0800
Subject: <AWT Dev> [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request:
 8198333 ProblemList should be updated for headless mode
In-Reply-To: <41e5a424-9cb3-95f9-9c29-9139fd8adfbc@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
 <5A8DA323.5000907@oracle.com>
 <41e5a424-9cb3-95f9-9c29-9139fd8adfbc@oracle.com>
Message-ID: <5A8DADE8.8010104@oracle.com>

That is fine.

-phil.

On 2/21/18, 9:34 AM, Sergey Bylokhov wrote:
> On 21/02/2018 08:49, Philip Race wrote:
>>> I am not sure it has mac specific code, I'll reevaluate this test in 
>>> JDK-8198406.
>>
>> This is mac-specific. It looks for specific fonts by name that exist 
>> only on MacOS.
>> And moreover the table handling in the implementation is relevant 
>> only for Apple AAT fonts ..
>> which you won't find anywhere else.
>> The one thing about this test that could change is that it doesn't 
>> need to create a Frame to
>> test this code -  drawing to a BI would suffice .. so it does not 
>> have to be headful with a few changes.
>
> I would not like to mix the test changes and updating the problem 
> list. I have filed a separate bugs for each test which should be 
> updated/reworked/fixed.
>
>

From jayathirth.d.v at oracle.com  Wed Feb 21 18:28:33 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Wed, 21 Feb 2018 10:28:33 -0800 (PST)
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <c40a8817-9f04-6dd7-03c7-c52383433e2c@oracle.com>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
 <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>
 <f59e6637-8f07-43be-aab6-11003815d4d0@default>
 <c40a8817-9f04-6dd7-03c7-c52383433e2c@oracle.com>
Message-ID: <8b323121-ff7a-4b9b-bf3c-5320ffa2180b@default>

Hi Sergey,

Thanks for your inputs.

In all the cases where Robot is working properly we expect all dnd operations to be finished within 2 mins, so we will never reach dropCount check in "new Thread".
In the case where Robot is not working properly we will not hit DropTargetAdapter.drop() so dropCount will not be updated.

I think since we have 2 min wait time after the first dnd operation is started,  we will not reach a condition where we will be accessing dropCount in parallel  at "new Thread" & drop callback. So there is no need of synchronization between these scenarios.

Thanks,
Jay

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, February 21, 2018 9:22 PM
To: Jayathirth D V
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting

Hi, Jay.
It looks like some synchronization is required when you access "dropCount" from two threads(the drop callback and the new added Thread).

On 21/02/2018 00:55, Jayathirth D V wrote:
> Hi Sergey,
> 
> Thanks for your inputs.
> I changed robot.mouseMouse() parameters and observed that if we don?t receive any updates in ImageDropTarget listener we will not dispose ImageDropTarget frame.
> I tried using ProcessCommunicator.destroyProcess() in finally block of ImageDragSource but it also didn?t dispose the ImageDropTarget frame.
> 
> So as suggested I have added 2 min wait in ImageDropTarget.main() and if we don?t receive anything in ImageDropTarget listener we will dispose() the frame. Usually in my machine it takes around 25seconds for DnD of all image formats so 2 minutes wait should be more than enough in all machines and different HiDPI scenarios.
> 
> Please find updated webrev for review:
> http://cr.openjdk.java.net/~jdv/8197926/webrev.03/
> 
> Thanks,
> Jay
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Saturday, February 17, 2018 1:36 AM
> To: Jayathirth D V
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: 
> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the 
> windows in HiDPI setting
> 
> Hi, Jay.
> There is one additional small issue, I have found it by run the test 
> on
> win10 where the robot does not work properly(separate bug). The subprocess still leaves the frame if the robot did not complete dnd properly. I think you can reproduce it by comment out all robot.mouseMove operations. The problem is that ImageDropTarget.main() did not dispose() the frame at the end of the method(it dispose it only in case of some errors). I think that the ImageDropTarget.main() should wait some amount of time and then throw an exception/dispose the frame/ or something like this. Or maybe the main process should kill/destroy the subprocess.
> 
> 
> On 15/02/2018 23:33, Jayathirth D V wrote:
>> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.
>>
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
>>
>> Thanks,
>> Jay
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Friday, February 16, 2018 3:28 AM
>> To: Jayathirth D V
>> Cc: awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close 
>> the windows in HiDPI setting
>>
>> Hi, Jay.
>>> I tried different failure scenarios inside test like making 
>>> comparing images fail but all the times frames are getting disposed.
>>> Could you please elaborate in which scenario exactly you are seeing 
>>> frame not getting disposed?
>>
>> I run the version of the test before your fix, and it leaves one of the frame of the screen.
>>
>>>
>>> But I have still added explicit frame.dispose() at places to make 
>>> sure that we dispose the created frames.
>>> Please find updated webrev for review:
>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>>
>>> Also in continuation to what we discussed offline, I used 
>>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command 
>>> prompt. But in this case also
>>> System.getProperty("sun.java2d.uiScale")
>>> returned null in test case. So I was not able to pass uiScale 
>>> mentioned in command prompt to ProcessCommunicator in test case.
>>
>> I tested it using this command line:
>> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10"
>> -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/
>> open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
>>
>> Plus this change in the test:
>>       public static void main(String[] arg) throws Exception {
>> +       String prop = System.getProperty("sun.java2d.uiScale");
>> +	System.err.println(prop);
>>
>> It prints 10 in the log.
>>
> 
> 
> --
> Best regards, Sergey.
> 


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Feb 21 20:19:31 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 12:19:31 -0800
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <8b323121-ff7a-4b9b-bf3c-5320ffa2180b@default>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
 <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>
 <f59e6637-8f07-43be-aab6-11003815d4d0@default>
 <c40a8817-9f04-6dd7-03c7-c52383433e2c@oracle.com>
 <8b323121-ff7a-4b9b-bf3c-5320ffa2180b@default>
Message-ID: <135b64c4-7d1d-ec3d-2e69-31b487754c5c@oracle.com>

Then it look fine,
Thank you for clarification.

On 21/02/2018 10:28, Jayathirth D V wrote:
> Hi Sergey,
> 
> Thanks for your inputs.
> 
> In all the cases where Robot is working properly we expect all dnd operations to be finished within 2 mins, so we will never reach dropCount check in "new Thread".
> In the case where Robot is not working properly we will not hit DropTargetAdapter.drop() so dropCount will not be updated.
> 
> I think since we have 2 min wait time after the first dnd operation is started,  we will not reach a condition where we will be accessing dropCount in parallel  at "new Thread" & drop callback. So there is no need of synchronization between these scenarios.
> 
> Thanks,
> Jay
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, February 21, 2018 9:22 PM
> To: Jayathirth D V
> Cc: awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the windows in HiDPI setting
> 
> Hi, Jay.
> It looks like some synchronization is required when you access "dropCount" from two threads(the drop callback and the new added Thread).
> 
> On 21/02/2018 00:55, Jayathirth D V wrote:
>> Hi Sergey,
>>
>> Thanks for your inputs.
>> I changed robot.mouseMouse() parameters and observed that if we don?t receive any updates in ImageDropTarget listener we will not dispose ImageDropTarget frame.
>> I tried using ProcessCommunicator.destroyProcess() in finally block of ImageDragSource but it also didn?t dispose the ImageDropTarget frame.
>>
>> So as suggested I have added 2 min wait in ImageDropTarget.main() and if we don?t receive anything in ImageDropTarget listener we will dispose() the frame. Usually in my machine it takes around 25seconds for DnD of all image formats so 2 minutes wait should be more than enough in all machines and different HiDPI scenarios.
>>
>> Please find updated webrev for review:
>> http://cr.openjdk.java.net/~jdv/8197926/webrev.03/
>>
>> Thanks,
>> Jay
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Saturday, February 17, 2018 1:36 AM
>> To: Jayathirth D V
>> Cc: awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
>> windows in HiDPI setting
>>
>> Hi, Jay.
>> There is one additional small issue, I have found it by run the test
>> on
>> win10 where the robot does not work properly(separate bug). The subprocess still leaves the frame if the robot did not complete dnd properly. I think you can reproduce it by comment out all robot.mouseMove operations. The problem is that ImageDropTarget.main() did not dispose() the frame at the end of the method(it dispose it only in case of some errors). I think that the ImageDropTarget.main() should wait some amount of time and then throw an exception/dispose the frame/ or something like this. Or maybe the main process should kill/destroy the subprocess.
>>
>>
>> On 15/02/2018 23:33, Jayathirth D V wrote:
>>> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" thing today and using System.getProperty("sun.java2d.uiScale") I am able to get the value inside test case. So I have modified the test case to pass scale value to ProcessCommunicator.executeChildProcess() and also I made some indentation changes in test case.
>>>
>>> Please find updated webrev for review:
>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
>>>
>>> Thanks,
>>> Jay
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Friday, February 16, 2018 3:28 AM
>>> To: Jayathirth D V
>>> Cc: awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
>>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close
>>> the windows in HiDPI setting
>>>
>>> Hi, Jay.
>>>> I tried different failure scenarios inside test like making
>>>> comparing images fail but all the times frames are getting disposed.
>>>> Could you please elaborate in which scenario exactly you are seeing
>>>> frame not getting disposed?
>>>
>>> I run the version of the test before your fix, and it leaves one of the frame of the screen.
>>>
>>>>
>>>> But I have still added explicit frame.dispose() at places to make
>>>> sure that we dispose the created frames.
>>>> Please find updated webrev for review:
>>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>>>
>>>> Also in continuation to what we discussed offline, I used
>>>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command
>>>> prompt. But in this case also
>>>> System.getProperty("sun.java2d.uiScale")
>>>> returned null in test case. So I was not able to pass uiScale
>>>> mentioned in command prompt to ProcessCommunicator in test case.
>>>
>>> I tested it using this command line:
>>> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10"
>>> -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/
>>> open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
>>>
>>> Plus this change in the test:
>>>        public static void main(String[] arg) throws Exception {
>>> +       String prop = System.getProperty("sun.java2d.uiScale");
>>> +	System.err.println(prop);
>>>
>>> It prints 10 in the log.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Thu Feb 22 00:32:32 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 21 Feb 2018 16:32:32 -0800
Subject: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test
 java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
In-Reply-To: <1e322c7a-166b-4bb4-939a-190e8b66a481@default>
References: <db33aee1-d651-4624-8cf2-16f802ded310@default>
 <7adf70be-3b00-ff6c-21d7-a9c4090b8523@oracle.com>
 <c280202e-2239-4104-9f82-842c98508f02@default>
 <a525f49b-4b4a-d82e-30db-ea3f6a23dda9@oracle.com>
 <c7de19ed-ba2f-5f10-a530-1f80d18c6a32@oracle.com>
 <6702d8d6-b2cc-4fac-b8ba-605cc4a1a4f8@default>
 <1e322c7a-166b-4bb4-939a-190e8b66a481@default>
Message-ID: <6e3f532d-8a1c-c563-54bb-8dbf71b65d05@oracle.com>

+1

--Semyon


On 02/20/2018 08:23 PM, Shashidhara Veerabhadraiah wrote:
> Hi, Please find the updated webrev per the comments:
> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.01/
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Shashidhara Veerabhadraiah
> Sent: Wednesday, February 21, 2018 9:22 AM
> To: Philip Race <philip.race at oracle.com>; Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
>
> Thank you Phil and Sergey for the clarification.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Phil Race
> Sent: Wednesday, February 21, 2018 2:26 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>; Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8129569: [TEST_BUG] Test java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java fails
>
> If jtreg ran all tests ran in othervm mode it would likely take much longer .. which is a big reason why the default is agentvm and not othervm.
> If the test destabilises the VM or is a resource hog, or needs VM special settings (eg setting a system property) then othervm would be the way to go.
>
> -phil.
>
>
> On 02/20/2018 11:23 AM, Sergey Bylokhov wrote:
>> On 20/02/2018 09:58, Shashidhara Veerabhadraiah wrote:
>>> But in general, isn't the othervm is preferable?
>> If it is not critical for the test it is better to use a default mode,
>> which maybe an agentvm(this mode can be faster than othervm).
>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Tuesday, February 20, 2018 8:06 PM
>>> To: Shashidhara Veerabhadraiah
>>> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
>>> Subject: Re: [11] JDK-8129569: [TEST_BUG] Test
>>> java/awt/Frame/MaximizedToUnmaximized/MaximizedToUnmaximized.java
>>> fails
>>>
>>> Hi, Shashi.
>>> Why have you changed the test to othervm?
>>>
>>> On 20/02/2018 02:09, Shashidhara Veerabhadraiah wrote:
>>>> Hi All, Please review a test bug fix for the below bug.
>>>>
>>>>                   Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8129569
>>>>
>>>>                   Webrev:
>>>> http://cr.openjdk.java.net/~sveerabhadra/8129569/webrev.00/
>>>>
>>>> Summary: This test was added as part of code fix for the bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8065739 under the changeset:
>>>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1457bd69ac5a. If one
>>>> examines the code updates done under this changeset it all relates
>>>> to the mac platform. Hence this test is updated to run on mac
>>>> platform only.
>>>>
>>>> Thanks and regards,
>>>> Shashi
>>>>
>>>
>>> --
>>> Best regards, Sergey.
>>>
>>


From prasanta.sadhukhan at oracle.com  Thu Feb 22 07:26:36 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 22 Feb 2018 12:56:36 +0530
Subject: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
 java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
 windows in HiDPI setting
In-Reply-To: <135b64c4-7d1d-ec3d-2e69-31b487754c5c@oracle.com>
References: <7d1c8f15-7621-4c58-8af2-a8c73e525a78@default>
 <35d23a6d-dd42-43e4-b61c-02e439d390ce@default>
 <21b04584-2bdc-b492-a6aa-ce3ffd5e58ae@oracle.com>
 <f59e6637-8f07-43be-aab6-11003815d4d0@default>
 <c40a8817-9f04-6dd7-03c7-c52383433e2c@oracle.com>
 <8b323121-ff7a-4b9b-bf3c-5320ffa2180b@default>
 <135b64c4-7d1d-ec3d-2e69-31b487754c5c@oracle.com>
Message-ID: <426e1d88-0c66-ac33-d470-6a424940f585@oracle.com>

+1

Regards
Prasanta
On 2/22/2018 1:49 AM, Sergey Bylokhov wrote:
> Then it look fine,
> Thank you for clarification.
>
> On 21/02/2018 10:28, Jayathirth D V wrote:
>> Hi Sergey,
>>
>> Thanks for your inputs.
>>
>> In all the cases where Robot is working properly we expect all dnd 
>> operations to be finished within 2 mins, so we will never reach 
>> dropCount check in "new Thread".
>> In the case where Robot is not working properly we will not hit 
>> DropTargetAdapter.drop() so dropCount will not be updated.
>>
>> I think since we have 2 min wait time after the first dnd operation 
>> is started,? we will not reach a condition where we will be accessing 
>> dropCount in parallel? at "new Thread" & drop callback. So there is 
>> no need of synchronization between these scenarios.
>>
>> Thanks,
>> Jay
>>
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Wednesday, February 21, 2018 9:22 PM
>> To: Jayathirth D V
>> Cc: awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926: 
>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close 
>> the windows in HiDPI setting
>>
>> Hi, Jay.
>> It looks like some synchronization is required when you access 
>> "dropCount" from two threads(the drop callback and the new added 
>> Thread).
>>
>> On 21/02/2018 00:55, Jayathirth D V wrote:
>>> Hi Sergey,
>>>
>>> Thanks for your inputs.
>>> I changed robot.mouseMouse() parameters and observed that if we 
>>> don?t receive any updates in ImageDropTarget listener we will not 
>>> dispose ImageDropTarget frame.
>>> I tried using ProcessCommunicator.destroyProcess() in finally block 
>>> of ImageDragSource but it also didn?t dispose the ImageDropTarget 
>>> frame.
>>>
>>> So as suggested I have added 2 min wait in ImageDropTarget.main() 
>>> and if we don?t receive anything in ImageDropTarget listener we will 
>>> dispose() the frame. Usually in my machine it takes around 25seconds 
>>> for DnD of all image formats so 2 minutes wait should be more than 
>>> enough in all machines and different HiDPI scenarios.
>>>
>>> Please find updated webrev for review:
>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.03/
>>>
>>> Thanks,
>>> Jay
>>>
>>> -----Original Message-----
>>> From: Sergey Bylokhov
>>> Sent: Saturday, February 17, 2018 1:36 AM
>>> To: Jayathirth D V
>>> Cc: awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
>>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close the
>>> windows in HiDPI setting
>>>
>>> Hi, Jay.
>>> There is one additional small issue, I have found it by run the test
>>> on
>>> win10 where the robot does not work properly(separate bug). The 
>>> subprocess still leaves the frame if the robot did not complete dnd 
>>> properly. I think you can reproduce it by comment out all 
>>> robot.mouseMove operations. The problem is that 
>>> ImageDropTarget.main() did not dispose() the frame at the end of the 
>>> method(it dispose it only in case of some errors). I think that the 
>>> ImageDropTarget.main() should wait some amount of time and then 
>>> throw an exception/dispose the frame/ or something like this. Or 
>>> maybe the main process should kill/destroy the subprocess.
>>>
>>>
>>> On 15/02/2018 23:33, Jayathirth D V wrote:
>>>> Strangely I tried the same -vmoptions:"-Dsun.java2d.uiScale=3" 
>>>> thing today and using System.getProperty("sun.java2d.uiScale") I am 
>>>> able to get the value inside test case. So I have modified the test 
>>>> case to pass scale value to 
>>>> ProcessCommunicator.executeChildProcess() and also I made some 
>>>> indentation changes in test case.
>>>>
>>>> Please find updated webrev for review:
>>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.02/
>>>>
>>>> Thanks,
>>>> Jay
>>>>
>>>> -----Original Message-----
>>>> From: Sergey Bylokhov
>>>> Sent: Friday, February 16, 2018 3:28 AM
>>>> To: Jayathirth D V
>>>> Cc: awt-dev at openjdk.java.net
>>>> Subject: Re: <AWT Dev> [AWT Dev] [11] RFR JDK-8197926:
>>>> java/awt/dnd/ImageTransferTest/ImageTransferTest.java doesnt close
>>>> the windows in HiDPI setting
>>>>
>>>> Hi, Jay.
>>>>> I tried different failure scenarios inside test like making
>>>>> comparing images fail but all the times frames are getting disposed.
>>>>> Could you please elaborate in which scenario exactly you are seeing
>>>>> frame not getting disposed?
>>>>
>>>> I run the version of the test before your fix, and it leaves one of 
>>>> the frame of the screen.
>>>>
>>>>>
>>>>> But I have still added explicit frame.dispose() at places to make
>>>>> sure that we dispose the created frames.
>>>>> Please find updated webrev for review:
>>>>> http://cr.openjdk.java.net/~jdv/8197926/webrev.01/
>>>>>
>>>>> Also in continuation to what we discussed offline, I used
>>>>> -vmoptions:"-Dsun.java2d.uiScale=2" to pass to jtreg from command
>>>>> prompt. But in this case also
>>>>> System.getProperty("sun.java2d.uiScale")
>>>>> returned null in test case. So I was not able to pass uiScale
>>>>> mentioned in command prompt to ProcessCommunicator in test case.
>>>>
>>>> I tested it using this command line:
>>>> ../jtreg/bin/jtreg -vmoptions:"-Dsun.java2d.uiScale=10"
>>>> -verbose:summary -a -nr -jdk:./build/windows-x64/images/jdk/
>>>> open/test/jdk/java/awt/dnd/ImageTransferTest/ImageTransferTest.java
>>>>
>>>> Plus this change in the test:
>>>> ?????? public static void main(String[] arg) throws Exception {
>>>> +?????? String prop = System.getProperty("sun.java2d.uiScale");
>>>> +??? System.err.println(prop);
>>>>
>>>> It prints 10 in the log.
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>>
>
>


From christoph.langer at sap.com  Thu Feb 22 12:54:55 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 22 Feb 2018 12:54:55 +0000
Subject: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED
 to the right component
In-Reply-To: <5e4eb1b4-5031-cef1-c375-2dce537e7299@oracle.com>
References: <6A983976-E274-4DBD-A10F-E682019D0C58@sap.com>
 <79f32162-7e4f-7e7d-9393-7ca783b754dd@oracle.com>
 <D3ED943D-010E-45AF-B8F2-92C8CB91F39B@sap.com>
 <5e4eb1b4-5031-cef1-c375-2dce537e7299@oracle.com>
Message-ID: <ce5c71e88caf45ddb1fa02d2a2234d20@sap.com>

Hi,

I?ve opened a bug for this: https://bugs.openjdk.java.net/browse/JDK-8198550

Best regards
Christoph


From: Semyon Sadetsky [mailto:semyon.sadetsky at oracle.com]
Sent: Dienstag, 9. Januar 2018 17:46
To: Weidemann, Matthias <matthias.weidemann at sap.com>; awt-dev at openjdk.java.net; Langer, Christoph <christoph.langer at sap.com>
Cc: Woersinger, Rolf-Martin <rolf-martin.woersinger at sap.com>; Denkel, Christian <christian.denkel at sap.com>
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Hello Matthias,

If so, please, file a bug to https://bugreport.java.com/

--Semyon

On 01/09/2018 12:09 AM, Weidemann, Matthias wrote:
Hello Sadetsky,

The discussion you linked to me seems to be a similar problem, but the fix discussed there happens specifically in the method Container.retargetMouseEnterExit(?). The problem we have happens in MOUSE_MOVED, so while this fix might fix the problem in the discussion it won?t fix ours.

Kind Regards,
Matthias

From: Semyon Sadetsky <semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
Date: Monday, January 8, 2018 at 10:55 PM
To: "Weidemann, Matthias" <matthias.weidemann at sap.com><mailto:matthias.weidemann at sap.com>, "awt-dev at openjdk.java.net"<mailto:awt-dev at openjdk.java.net> <awt-dev at openjdk.java.net><mailto:awt-dev at openjdk.java.net>
Cc: "Woersinger, Rolf-Martin" <rolf-martin.woersinger at sap.com><mailto:rolf-martin.woersinger at sap.com>, "Denkel, Christian" <christian.denkel at sap.com><mailto:christian.denkel at sap.com>
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Hi Matthias,

Thank you for your e-mail.

It seems a fix for this bug is already under discussion on this thread:

http://mail.openjdk.java.net/pipermail/swing-dev/2017-December/008077.html

--Semyon

On 01/04/2018 04:56 AM, Weidemann, Matthias wrote:
Hello everyone,

we found a rare occurrence of a bug in JDK1.8 and onwards, might also occur earlier but we didn?t check for that.

In some instances MOUSE_MOVED events occur between a MOUSE_PRESSED and a MOUSE_RELEASED. In Container.java on MOUSE_PRESSED the component is remembered in an instance variable to send a corresponding MOUSE_RELEASED to it.
The same instance variable is used for the MOUSE_MOVED Event, so if there are MOUSE_MOVED Events between a MOUSE_PRESSED and MOUSE_RELEASED the corresponding MOUSE_RELEASE will be reported to the "wrong" component.

I attached a simple example to replicate the error.

I included hardware specifications, because the occurrence fluctuates with the hardware used. We got the best results to reproduce with the Macbook and the magic mouse shown below. With a trackpad it is almost impossible to replicate.





How to: Move the mouse in the blue rectangle VERY FAST from left to right or vice versa. Release the mousebutton near the end of the drag, while you are still in motion.

We are using a workaround for this, the same custom queue built into the example. If we are between MOUSE_PRESSED and MOUSE_RELEASED we do not dispatch MOUSE_MOVED Events.
We would still like to see this bug fixed or at least have different instance variables for MOUSE_PRESSED and MOUSE_MOVED so we get the MOUSE_RELEASE on the right component.

Kind Regards,
Matthias Weidemann

Matthias Weidemann
Software Developer, PI Technology UxP UI P&S (SE) Supp
SAP SE, Opelstr. 6, 68789 St. Leon - Rot, Germany

T +49 6227 7-45771 , E matthias.weidemann at sap.com<mailto:matthias.weidemann at sap.com>


Please consider the impact on the environment before printing this e-mail.


Pflichtangaben/Mandatory Disclosure Statement:
http://www.sap.com/company/legal/impressum.epx/<http://www.sap.com/company/legal/impressum.epx>

Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal.
Thank you for your cooperation





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/734610e0/attachment.html>

From semyon.sadetsky at oracle.com  Thu Feb 22 18:28:00 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 22 Feb 2018 10:28:00 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
Message-ID: <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>

Hi Shashi,

Can you clarify what is the principal difference between 
SCROLLBARS_NEVER and other scroll policies that requires to avoid 
updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
>
> Hi All, Please review a code fix for the below bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195738
>
> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>
> Problematic platform: Windows only.
>
> Summary: This bug occurs only on windows platform and whereas the 
> behavior is different on Mac/Linux platforms. Now after this fix there 
> is common behavior across the platforms.
>
> The main problem was with resetting the state of the scroll bars even 
> though the scroll bar panes are spawned with SCROLLBARS_NEVER as the 
> scroll bar display policy. This resetting should not occur as the 
> scroll bar display policy makes the
>
> scroll bar panes invisible. Hence except the setScrollPosition() 
> calls, we don?t need to resize/update the scroll bars state upon 
> calling the scroll bars validation if SCROLLBARS_NEVER policy is used 
> as the scroll bars are not displayed.
>
> Thanks and regards,
> Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/26e5d058/attachment-0001.html>

From semyon.sadetsky at oracle.com  Thu Feb 22 18:16:27 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 22 Feb 2018 10:16:27 -0800
Subject: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED
 to the right component
In-Reply-To: <ce5c71e88caf45ddb1fa02d2a2234d20@sap.com>
References: <6A983976-E274-4DBD-A10F-E682019D0C58@sap.com>
 <79f32162-7e4f-7e7d-9393-7ca783b754dd@oracle.com>
 <D3ED943D-010E-45AF-B8F2-92C8CB91F39B@sap.com>
 <5e4eb1b4-5031-cef1-c375-2dce537e7299@oracle.com>
 <ce5c71e88caf45ddb1fa02d2a2234d20@sap.com>
Message-ID: <f53af1d2-8454-3043-df03-52fcafe03024@oracle.com>

Thank you, Christoph. It will be prioritized and assigned to Oracle 
engineer soon. If you are interested to get it evaluated more quickly 
feel free to propose a patch on this alias and it will be reviewed and 
sponsored.

--Semyon



On 02/22/2018 04:54 AM, Langer, Christoph wrote:
>
> Hi,
>
> I?ve opened a bug for this: 
> https://bugs.openjdk.java.net/browse/JDK-8198550
>
> Best regards
>
> Christoph
>
> *From:*Semyon Sadetsky [mailto:semyon.sadetsky at oracle.com]
> *Sent:* Dienstag, 9. Januar 2018 17:46
> *To:* Weidemann, Matthias <matthias.weidemann at sap.com>; 
> awt-dev at openjdk.java.net; Langer, Christoph <christoph.langer at sap.com>
> *Cc:* Woersinger, Rolf-Martin <rolf-martin.woersinger at sap.com>; 
> Denkel, Christian <christian.denkel at sap.com>
> *Subject:* Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching 
> MOUSE_RELEASED to the right component
>
> Hello Matthias,
>
> If so, please, file a bug to https://bugreport.java.com/
>
> --Semyon
>
> On 01/09/2018 12:09 AM, Weidemann, Matthias wrote:
>
>     Hello Sadetsky,
>
>     The discussion you linked to me seems to be a similar problem, but
>     the fix discussed there happens specifically in the method
>     Container.retargetMouseEnterExit(?). The problem we have happens
>     in MOUSE_MOVED, so while this fix might fix the problem in the
>     discussion it won?t fix ours.
>
>     Kind Regards,
>
>     Matthias
>
>     *From: *Semyon Sadetsky <semyon.sadetsky at oracle.com>
>     <mailto:semyon.sadetsky at oracle.com>
>     *Date: *Monday, January 8, 2018 at 10:55 PM
>     *To: *"Weidemann, Matthias" <matthias.weidemann at sap.com>
>     <mailto:matthias.weidemann at sap.com>, "awt-dev at openjdk.java.net"
>     <mailto:awt-dev at openjdk.java.net> <awt-dev at openjdk.java.net>
>     <mailto:awt-dev at openjdk.java.net>
>     *Cc: *"Woersinger, Rolf-Martin" <rolf-martin.woersinger at sap.com>
>     <mailto:rolf-martin.woersinger at sap.com>, "Denkel, Christian"
>     <christian.denkel at sap.com> <mailto:christian.denkel at sap.com>
>     *Subject: *Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching
>     MOUSE_RELEASED to the right component
>
>     Hi Matthias,
>
>     Thank you for your e-mail.
>
>     It seems a fix for this bug is already under discussion on this
>     thread:
>
>     http://mail.openjdk.java.net/pipermail/swing-dev/2017-December/008077.html
>
>     --Semyon
>
>     On 01/04/2018 04:56 AM, Weidemann, Matthias wrote:
>
>         Hello everyone,
>
>         we found a rare occurrence of a bug in JDK1.8 and onwards,
>         might also occur earlier but we didn?t check for that.
>
>         In some instances MOUSE_MOVED events occur between a
>         MOUSE_PRESSED and a MOUSE_RELEASED. In Container.java on
>         MOUSE_PRESSED the component is remembered in an instance
>         variable to send a corresponding MOUSE_RELEASED to it.
>
>         The same instance variable is used for the MOUSE_MOVED Event,
>         so if there are MOUSE_MOVED Events between a MOUSE_PRESSED and
>         MOUSE_RELEASED the corresponding MOUSE_RELEASE will be
>         reported to the "wrong" component.
>
>         I attached a simple example to replicate the error.
>
>         I included hardware specifications, because the occurrence
>         fluctuates with the hardware used. We got the best results to
>         reproduce with the Macbook and the magic mouse shown below.
>         With a trackpad it is almost impossible to replicate.
>
>         *How to:*Move the mouse in the blue rectangle VERY FAST from
>         left to right or vice versa. Release the mousebutton near the
>         end of the drag, while you are still in motion.
>
>         We are using a workaround for this, the same custom queue
>         built into the example. If we are between MOUSE_PRESSED and
>         MOUSE_RELEASED we do not dispatch MOUSE_MOVED Events.
>
>         We would still like to see this bug fixed or at least have
>         different instance variables for MOUSE_PRESSED and MOUSE_MOVED
>         so we get the MOUSE_RELEASE on the right component.
>
>         Kind Regards,
>
>         Matthias Weidemann
>
>         *Matthias Weidemann
>         *Software Developer, PI Technology UxP UI P&S (SE) Supp
>         *SAP SE*, Opelstr. 6, 68789 St. Leon - Rot, Germany
>
>         T +49 6227 7-45771 , E matthias.weidemann at sap.com
>         <mailto:matthias.weidemann at sap.com>
>         *
>
>         Please consider the impact on the environment before printing
>         this e-mail.
>         *
>
>         Pflichtangaben/Mandatory Disclosure Statement:
>         http://www.sap.com/company/legal/impressum.epx/
>         <http://www.sap.com/company/legal/impressum.epx>
>
>         Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder
>         sonstige vertrauliche Informationen enthalten. Sollten Sie
>         diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine
>         Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder
>         Weitergabe der E-Mail ausdr?cklich untersagt. Bitte
>         benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
>         Vielen Dank.
>
>         This e-mail may contain trade secrets or privileged,
>         undisclosed, or otherwise confidential information. If you
>         have received this e-mail in error, you are hereby notified
>         that any review, copying, or distribution of it is strictly
>         prohibited. Please inform us immediately and destroy the
>         original transmittal.
>         Thank you for your cooperation
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/5798b09f/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Feb 23 04:23:50 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Thu, 22 Feb 2018 20:23:50 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
Message-ID: <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>

Hi Semyon, Thanks for your review comments.

 

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

 

Thanks and regards,
Shashi

 

From: Semyon Sadetsky 
Sent: Thursday, February 22, 2018 11:58 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

 

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8195738

 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

 

Problematic platform: Windows only.

 

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the 

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don't need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

 

Thanks and regards,
Shashi

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/178dda84/attachment-0001.html>

From christoph.langer at sap.com  Fri Feb 23 09:01:26 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 23 Feb 2018 09:01:26 +0000
Subject: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED
 to the right component
In-Reply-To: <f53af1d2-8454-3043-df03-52fcafe03024@oracle.com>
References: <6A983976-E274-4DBD-A10F-E682019D0C58@sap.com>
 <79f32162-7e4f-7e7d-9393-7ca783b754dd@oracle.com>
 <D3ED943D-010E-45AF-B8F2-92C8CB91F39B@sap.com>
 <5e4eb1b4-5031-cef1-c375-2dce537e7299@oracle.com>
 <ce5c71e88caf45ddb1fa02d2a2234d20@sap.com>
 <f53af1d2-8454-3043-df03-52fcafe03024@oracle.com>
Message-ID: <5856eedfb8a14c70a0d9ece7160ad31c@sap.com>

Hi Semyon,

yes, I had a quick try on it yesterday but I couldn?t even get it reproduced on my personal infrastructure. Neither on Mac nor on Windows. The colleagues say that the likelihood of this error is a quite scenario/hardware specific? Plus, I?m not an expert in the GUI area. So I?m hoping on some Oracle/community expertise here?

Thanks,
Christoph

From: Semyon Sadetsky [mailto:semyon.sadetsky at oracle.com]
Sent: Donnerstag, 22. Februar 2018 19:16
To: Langer, Christoph <christoph.langer at sap.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Thank you, Christoph. It will be prioritized and assigned to Oracle engineer soon. If you are interested to get it evaluated more quickly feel free to propose a patch on this alias and it will be reviewed and sponsored.

--Semyon



On 02/22/2018 04:54 AM, Langer, Christoph wrote:
Hi,

I?ve opened a bug for this: https://bugs.openjdk.java.net/browse/JDK-8198550

Best regards
Christoph


From: Semyon Sadetsky [mailto:semyon.sadetsky at oracle.com]
Sent: Dienstag, 9. Januar 2018 17:46
To: Weidemann, Matthias <matthias.weidemann at sap.com><mailto:matthias.weidemann at sap.com>; awt-dev at openjdk.java.net<mailto:awt-dev at openjdk.java.net>; Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>
Cc: Woersinger, Rolf-Martin <rolf-martin.woersinger at sap.com><mailto:rolf-martin.woersinger at sap.com>; Denkel, Christian <christian.denkel at sap.com><mailto:christian.denkel at sap.com>
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Hello Matthias,

If so, please, file a bug to https://bugreport.java.com/

--Semyon

On 01/09/2018 12:09 AM, Weidemann, Matthias wrote:
Hello Sadetsky,

The discussion you linked to me seems to be a similar problem, but the fix discussed there happens specifically in the method Container.retargetMouseEnterExit(?). The problem we have happens in MOUSE_MOVED, so while this fix might fix the problem in the discussion it won?t fix ours.

Kind Regards,
Matthias

From: Semyon Sadetsky <semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
Date: Monday, January 8, 2018 at 10:55 PM
To: "Weidemann, Matthias" <matthias.weidemann at sap.com><mailto:matthias.weidemann at sap.com>, "awt-dev at openjdk.java.net"<mailto:awt-dev at openjdk.java.net> <awt-dev at openjdk.java.net><mailto:awt-dev at openjdk.java.net>
Cc: "Woersinger, Rolf-Martin" <rolf-martin.woersinger at sap.com><mailto:rolf-martin.woersinger at sap.com>, "Denkel, Christian" <christian.denkel at sap.com><mailto:christian.denkel at sap.com>
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Hi Matthias,

Thank you for your e-mail.

It seems a fix for this bug is already under discussion on this thread:

http://mail.openjdk.java.net/pipermail/swing-dev/2017-December/008077.html

--Semyon

On 01/04/2018 04:56 AM, Weidemann, Matthias wrote:
Hello everyone,

we found a rare occurrence of a bug in JDK1.8 and onwards, might also occur earlier but we didn?t check for that.

In some instances MOUSE_MOVED events occur between a MOUSE_PRESSED and a MOUSE_RELEASED. In Container.java on MOUSE_PRESSED the component is remembered in an instance variable to send a corresponding MOUSE_RELEASED to it.
The same instance variable is used for the MOUSE_MOVED Event, so if there are MOUSE_MOVED Events between a MOUSE_PRESSED and MOUSE_RELEASED the corresponding MOUSE_RELEASE will be reported to the "wrong" component.

I attached a simple example to replicate the error.

I included hardware specifications, because the occurrence fluctuates with the hardware used. We got the best results to reproduce with the Macbook and the magic mouse shown below. With a trackpad it is almost impossible to replicate.





How to: Move the mouse in the blue rectangle VERY FAST from left to right or vice versa. Release the mousebutton near the end of the drag, while you are still in motion.

We are using a workaround for this, the same custom queue built into the example. If we are between MOUSE_PRESSED and MOUSE_RELEASED we do not dispatch MOUSE_MOVED Events.
We would still like to see this bug fixed or at least have different instance variables for MOUSE_PRESSED and MOUSE_MOVED so we get the MOUSE_RELEASE on the right component.

Kind Regards,
Matthias Weidemann

Matthias Weidemann
Software Developer, PI Technology UxP UI P&S (SE) Supp
SAP SE, Opelstr. 6, 68789 St. Leon - Rot, Germany

T +49 6227 7-45771 , E matthias.weidemann at sap.com<mailto:matthias.weidemann at sap.com>


Please consider the impact on the environment before printing this e-mail.


Pflichtangaben/Mandatory Disclosure Statement:
http://www.sap.com/company/legal/impressum.epx/<http://www.sap.com/company/legal/impressum.epx>

Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal.
Thank you for your cooperation







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180223/18443597/attachment-0001.html>

From christoph.langer at sap.com  Thu Feb 22 12:50:15 2018
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 22 Feb 2018 12:50:15 +0000
Subject: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED
 to the right component
In-Reply-To: <5e4eb1b4-5031-cef1-c375-2dce537e7299@oracle.com>
References: <6A983976-E274-4DBD-A10F-E682019D0C58@sap.com>
 <79f32162-7e4f-7e7d-9393-7ca783b754dd@oracle.com>
 <D3ED943D-010E-45AF-B8F2-92C8CB91F39B@sap.com>
 <5e4eb1b4-5031-cef1-c375-2dce537e7299@oracle.com>
Message-ID: <b7ed21d58a56497bbfbba57c7f71aad4@sap.com>

Hi,

I?ve opened a bug for this: https://bugs.openjdk.java.net/browse/JDK-8198550

Best regards
Christoph

From: Semyon Sadetsky [mailto:semyon.sadetsky at oracle.com]
Sent: Dienstag, 9. Januar 2018 17:46
To: Weidemann, Matthias <matthias.weidemann at sap.com>; awt-dev at openjdk.java.net; Langer, Christoph <christoph.langer at sap.com>
Cc: Woersinger, Rolf-Martin <rolf-martin.woersinger at sap.com>; Denkel, Christian <christian.denkel at sap.com>
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Hello Matthias,

If so, please, file a bug to https://bugreport.java.com/

--Semyon

On 01/09/2018 12:09 AM, Weidemann, Matthias wrote:
Hello Sadetsky,

The discussion you linked to me seems to be a similar problem, but the fix discussed there happens specifically in the method Container.retargetMouseEnterExit(?). The problem we have happens in MOUSE_MOVED, so while this fix might fix the problem in the discussion it won?t fix ours.

Kind Regards,
Matthias

From: Semyon Sadetsky <semyon.sadetsky at oracle.com><mailto:semyon.sadetsky at oracle.com>
Date: Monday, January 8, 2018 at 10:55 PM
To: "Weidemann, Matthias" <matthias.weidemann at sap.com><mailto:matthias.weidemann at sap.com>, "awt-dev at openjdk.java.net"<mailto:awt-dev at openjdk.java.net> <awt-dev at openjdk.java.net><mailto:awt-dev at openjdk.java.net>
Cc: "Woersinger, Rolf-Martin" <rolf-martin.woersinger at sap.com><mailto:rolf-martin.woersinger at sap.com>, "Denkel, Christian" <christian.denkel at sap.com><mailto:christian.denkel at sap.com>
Subject: Re: <AWT Dev> Unwanted MOUSE_MOVED break dispatching MOUSE_RELEASED to the right component


Hi Matthias,

Thank you for your e-mail.

It seems a fix for this bug is already under discussion on this thread:

http://mail.openjdk.java.net/pipermail/swing-dev/2017-December/008077.html

--Semyon

On 01/04/2018 04:56 AM, Weidemann, Matthias wrote:
Hello everyone,

we found a rare occurrence of a bug in JDK1.8 and onwards, might also occur earlier but we didn?t check for that.

In some instances MOUSE_MOVED events occur between a MOUSE_PRESSED and a MOUSE_RELEASED. In Container.java on MOUSE_PRESSED the component is remembered in an instance variable to send a corresponding MOUSE_RELEASED to it.
The same instance variable is used for the MOUSE_MOVED Event, so if there are MOUSE_MOVED Events between a MOUSE_PRESSED and MOUSE_RELEASED the corresponding MOUSE_RELEASE will be reported to the "wrong" component.

I attached a simple example to replicate the error.

I included hardware specifications, because the occurrence fluctuates with the hardware used. We got the best results to reproduce with the Macbook and the magic mouse shown below. With a trackpad it is almost impossible to replicate.

[cid:image001.jpg at 01D3ABE4.108262F0][cid:image002.jpg at 01D3ABE4.108262F0][cid:image003.jpg at 01D3ABE4.108262F0]



How to: Move the mouse in the blue rectangle VERY FAST from left to right or vice versa. Release the mousebutton near the end of the drag, while you are still in motion.

We are using a workaround for this, the same custom queue built into the example. If we are between MOUSE_PRESSED and MOUSE_RELEASED we do not dispatch MOUSE_MOVED Events.
We would still like to see this bug fixed or at least have different instance variables for MOUSE_PRESSED and MOUSE_MOVED so we get the MOUSE_RELEASE on the right component.

Kind Regards,
Matthias Weidemann

Matthias Weidemann
Software Developer, PI Technology UxP UI P&S (SE) Supp
SAP SE, Opelstr. 6, 68789 St. Leon - Rot, Germany

T +49 6227 7-45771 , E matthias.weidemann at sap.com<mailto:matthias.weidemann at sap.com>


Please consider the impact on the environment before printing this e-mail.


Pflichtangaben/Mandatory Disclosure Statement:
http://www.sap.com/company/legal/impressum.epx/<http://www.sap.com/company/legal/impressum.epx>

Diese E-Mail kann Betriebs- oder Gesch?ftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrt?mlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielf?ltigung oder Weitergabe der E-Mail ausdr?cklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail.
Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal.
Thank you for your cooperation





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/a0d1c635/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 80021 bytes
Desc: image001.jpg
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/a0d1c635/image001-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 79182 bytes
Desc: image002.jpg
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/a0d1c635/image002-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 78333 bytes
Desc: image003.jpg
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180222/a0d1c635/image003-0001.jpg>

From semyon.sadetsky at oracle.com  Fri Feb 23 16:47:02 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 23 Feb 2018 08:47:02 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
Message-ID: <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

> Hi Semyon, Thanks for your review comments.
>
> Here are those different scroll bar pane modes and their description:
>
> *Modifier and Type***
>
> 	
>
> *Field*
>
> 	
>
> *Description*
>
> |static int|
>
> 	
>
> *SCROLLBARS_ALWAYS 
> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>
> 	
>
> Specifies that horizontal/vertical scrollbars should always be shown 
> regardless of the respective sizes of the scrollpane and child.
>
> |static int|
>
> 	
>
> *SCROLLBARS_AS_NEEDED 
> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>
> 	
>
> Specifies that horizontal/vertical scrollbar should be shown only when 
> the size of the child exceeds the size of the scrollpane in the 
> horizontal/vertical dimension.
>
> |static int|
>
> 	
>
> *SCROLLBARS_NEVER 
> <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>
> 	
>
> Specifies that horizontal/vertical scrollbars should never be shown 
> regardless of the respective sizes of the scrollpane and child.
>
This javadoc, you've copy-pasted here, doesn't explain why in your fix 
the notification about changed child size is disabled for 
SCROLLBARS_NEVER case.
>
> Thanks and regards,
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Thursday, February 22, 2018 11:58 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
> ScrollPane is reset after calling validate()
>
> Hi Shashi,
>
> Can you clarify what is the principal difference between 
> SCROLLBARS_NEVER and other scroll policies that requires to avoid 
> updating the scroll geometry according to the inner component size?
>
> --Semyon
>
> On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
>
>     Hi All, Please review a code fix for the below bug.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8195738
>
>     Webrev:
>     http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>     <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>
>     Problematic platform: Windows only.
>
>     Summary: This bug occurs only on windows platform and whereas the
>     behavior is different on Mac/Linux platforms. Now after this fix
>     there is common behavior across the platforms.
>
>     The main problem was with resetting the state of the scroll bars
>     even though the scroll bar panes are spawned with SCROLLBARS_NEVER
>     as the scroll bar display policy. This resetting should not occur
>     as the scroll bar display policy makes the
>
>     scroll bar panes invisible. Hence except the setScrollPosition()
>     calls, we don?t need to resize/update the scroll bars state upon
>     calling the scroll bars validation if SCROLLBARS_NEVER policy is
>     used as the scroll bars are not displayed.
>
>     Thanks and regards,
>     Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180223/ff4cc96d/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Fri Feb 23 18:57:15 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Fri, 23 Feb 2018 10:57:15 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
Message-ID: <9447653d-6931-48a7-95e6-c72edd2defaa@default>

Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?

 

Scroll pane geometry gets updated in 2 ways, one thro' setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don't display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn't made any difference.

 

Thanks and regards,
Shashi

 

From: Semyon Sadetsky 
Sent: Friday, February 23, 2018 10:17 PM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

 

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review comments.

 

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

 

This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case. 

Thanks and regards,
Shashi

 

From: Semyon Sadetsky 
Sent: Thursday, February 22, 2018 11:58 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

 

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8195738

 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

 

Problematic platform: Windows only.

 

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the 

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don't need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

 

Thanks and regards,
Shashi

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180223/6c27ae2f/attachment-0001.html>

From semyon.sadetsky at oracle.com  Fri Feb 23 20:42:00 2018
From: semyon.sadetsky at oracle.com (semyon.sadetsky at oracle.com)
Date: Fri, 23 Feb 2018 12:42:00 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <9447653d-6931-48a7-95e6-c72edd2defaa@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
Message-ID: <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>

On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:

> Hi Semyon, Whenever the container is resized we used to update the 
> scroll pane sizes/geometry regardless of the scroll bar display 
> policies. This resizing make sense for the non SCROLLBARS_NEVER cases 
> as the scroll pane is displayed or needed an update. This additional 
> update posed issues for the SCROLLBARS_NEVER case where we are not 
> supposed to display the scroll pane per the java doc, then why update?
>
> Scroll pane geometry gets updated in 2 ways, one thro? 
> setScrollPosition() and childResized(). So I derived the conclusion 
> based on the javadoc information that since we don?t display the 
> scroll pane there is no need to update the scroll pane geometry based 
> on the childResized() as it was altering the position already set by 
> the setScrollPosition(). This behavior is same as the other non 
> SCROLLBARS_NEVER mode and setting the scroll bar display to 
> SCROLLBARS_NEVER didn?t made any difference.
>
The only difference of SCROLLBARS_NEVER from others I got from javadoc 
is that the scroll bar controls are hidden. So the scrolling itself 
happens in the same way as in the case of visible scroll bars but it can 
be only controlled by mouse wheel or programmatically. In my 
understanding this means that the notification about the scrolled 
component size changes should happen in the same way as for all other 
cases. I see no reason for the differentiation that your fix introduces. 
What will happen if to remove this notification for visible scroll bars 
modes?

--Semyon
>
> Thanks and regards,
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Friday, February 23, 2018 10:17 PM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
> ScrollPane is reset after calling validate()
>
> On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Semyon, Thanks for your review comments.
>
>     Here are those different scroll bar pane modes and their description:
>
>     *Modifier and Type*
>
>     	
>
>     *Field*
>
>     	
>
>     *Description*
>
>     |static int|
>
>     	
>
>     *SCROLLBARS_ALWAYS
>     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>
>     	
>
>     Specifies that horizontal/vertical scrollbars should always be
>     shown regardless of the respective sizes of the scrollpane and child.
>
>     |static int|
>
>     	
>
>     *SCROLLBARS_AS_NEEDED
>     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>
>     	
>
>     Specifies that horizontal/vertical scrollbar should be shown only
>     when the size of the child exceeds the size of the scrollpane in
>     the horizontal/vertical dimension.
>
>     |static int|
>
>     	
>
>     *SCROLLBARS_NEVER
>     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>
>     	
>
>     Specifies that horizontal/vertical scrollbars should never be
>     shown regardless of the respective sizes of the scrollpane and child.
>
> This javadoc, you've copy-pasted here, doesn't explain why in your fix 
> the notification about changed child size is disabled for 
> SCROLLBARS_NEVER case.
>
>     Thanks and regards,
>     Shashi
>
>     *From:*Semyon Sadetsky
>     *Sent:* Thursday, February 22, 2018 11:58 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>     ScrollPane is reset after calling validate()
>
>     Hi Shashi,
>
>     Can you clarify what is the principal difference between
>     SCROLLBARS_NEVER and other scroll policies that requires to avoid
>     updating the scroll geometry according to the inner component size?
>
>     --Semyon
>
>     On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
>
>         Hi All, Please review a code fix for the below bug.
>
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8195738
>
>         Webrev:
>         http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>         <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>
>         Problematic platform: Windows only.
>
>         Summary: This bug occurs only on windows platform and whereas
>         the behavior is different on Mac/Linux platforms. Now after
>         this fix there is common behavior across the platforms.
>
>         The main problem was with resetting the state of the scroll
>         bars even though the scroll bar panes are spawned with
>         SCROLLBARS_NEVER as the scroll bar display policy. This
>         resetting should not occur as the scroll bar display policy
>         makes the
>
>         scroll bar panes invisible. Hence except the
>         setScrollPosition() calls, we don?t need to resize/update the
>         scroll bars state upon calling the scroll bars validation if
>         SCROLLBARS_NEVER policy is used as the scroll bars are not
>         displayed.
>
>         Thanks and regards,
>         Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180223/9e2b661f/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Sat Feb 24 13:27:40 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sat, 24 Feb 2018 05:27:40 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
Message-ID: <94e04514-2c02-4a57-b0f1-063508022355@default>

Hi Semyon, Thanks for your review and these questions help us to reach the right requirements. 

 

Without this change, there is different behavior on windows compared to Mac/Linux platforms. Hence this change is required to make the behavior same across the platforms. Since the scroll pane control is not displayed for the SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the user can move to a different position? Since we used to update/recalculate the scroll pane geometry caused changes to move to a different position other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the user is unable to control the scrolling movement because neither he can set one setScrollPosition() nor the control is displayed to explicitly set the movement. Hope this answers your question.

 

Thanks and regards,
Shashi

 

From: Semyon Sadetsky 
Sent: Saturday, February 24, 2018 2:12 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

 

On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?

 

Scroll pane geometry gets updated in 2 ways, one thro' setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don't display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn't made any difference.

The only difference of SCROLLBARS_NEVER from others I got from javadoc is that the scroll bar controls are hidden. So the scrolling itself happens in the same way as in the case of visible scroll bars but it can be only controlled by mouse wheel or programmatically. In my understanding this means that the notification about the scrolled component size changes should happen in the same way as for all other cases. I see no reason for the differentiation that your fix introduces. What will happen if to remove this notification for visible scroll bars modes?

--Semyon



 

Thanks and regards,
Shashi

 

From: Semyon Sadetsky 
Sent: Friday, February 23, 2018 10:17 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

 

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review comments.

 

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

 

This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case. 

Thanks and regards,
Shashi

 

From: Semyon Sadetsky 
Sent: Thursday, February 22, 2018 11:58 PM
To: Shashidhara Veerabhadraiah HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

 

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8195738

 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

 

Problematic platform: Windows only.

 

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the 

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don't need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

 

Thanks and regards,
Shashi

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180224/91f167f8/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Sat Feb 24 15:32:25 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Sat, 24 Feb 2018 07:32:25 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
Message-ID: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>

Hi All, Please review a test fix for the below bug:

 

        Bug: https://bugs.openjdk.java.net/browse/JDK-8196017

 

        Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/

 

Summary: The original bug https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only for MacOS platform but the test is enabled to run on all platforms. This is modified. Along with it exact positional comparison was done in the test and now modified to allow for leniency of around 2 pixels.

 

Thanks and regards,
Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180224/d915ecd3/attachment-0001.html>

From krishna.addepalli at oracle.com  Mon Feb 26 01:53:32 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Sun, 25 Feb 2018 17:53:32 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
Message-ID: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>

Hi All,

 

Please review a fix for JDK-8197808: https://bugs.openjdk.java.net/browse/JDK-8197808

Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/

 

The problem was that by the time Robot tries to read the color on screen, the compositing of the window is not completed, and hence, instead of reading Blue color, it is reading a combination of Blue and Red colors. Increasing the delay by 100 ms made sure that the composition is complete and the color is being read correctly. Also, this happens only on Windows 10.

Apart from this, the test was not cleaning up the windows when it throws exception, so fixed that, and also added all explicit imports.

 

Thanks,

Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180225/aeefa921/attachment.html>

From prem.balakrishnan at oracle.com  Mon Feb 26 05:29:29 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Sun, 25 Feb 2018 21:29:29 -0800 (PST)
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
Message-ID: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>

Hi All,

 

Please review fix for JDK 11:

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8196435

 

Webrev: http://cr.openjdk.java.net/~pkbalakr/8196435/webrev.00/ 

 

Test fails due to synchronization issue. 

 

Regards,

Prem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180225/308bca2f/attachment.html>

From manajit.halder at oracle.com  Mon Feb 26 07:58:31 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 26 Feb 2018 13:28:31 +0530
Subject: <AWT Dev> Subject: <AWT dev>[11] Review request for
 JDK-7158623: [macosx] Should an unfocusable maximized Frame be resizable?
In-Reply-To: <1506b6ce-01db-ddbb-d00f-6647a62c76fc@oracle.com>
References: <D9D0E2F1-34F0-4ACC-B2A4-A8C945D519A8@oracle.com>
 <5A870416.1030009@oracle.com>
 <1506b6ce-01db-ddbb-d00f-6647a62c76fc@oracle.com>
Message-ID: <0D6F1EFB-65B5-4823-B136-6DE71AA4DA28@oracle.com>

Hi Phil and Kevin,

Sorry for specifying wrong JDK version. This review is for JDK 11.

Regarding spec:
   	It is not mentioned in the focus spec whether the unfocusable maximized frames should be resizable or not.
   	The fix is given based on the implementation on other platforms (windows and linux/unix) . On both the platforms (windows and unix/linux) the test passes whereas the test fails on Mac.
	An old Issue https://bugs.openjdk.java.net/browse/JDK-4980161 <https://bugs.openjdk.java.net/browse/JDK-4980161> is related to this fix.
  
Regarding fix:
	The test case java/awt/Frame/UnfocusableMaximizedFrameResizablity/UnfocusableMaximizedFrameResizablity.java fails on Mac and passes on windows and linux/unix.
	As per the test case when setFocusableWindowState is set to false frame should not be resizable. 
	updateFocusableWindowState() updates the window focusable state and the fix under review sets RESIZABLE property to true or false based on focusability of the frame.
	
Regards,
Manajit


> webrev appears to be against the correct repo :
> sh://hg.openjdk.java.net/jdk/client 
> 
> 
> First can you point to what in the spec. or whatever points to
> the correct desired behaviour being what you describe :
> >If the frame is focusable then it is resizable otherwise not.
> 
> And regarding the fix, it isn't obvious how adding RESIZABLE changes anything here
> for the unfocusable case which seems to be the situation that is under discussion.
> 
> Before: if its unfocusable, then setStyleBits will set the mask to 0 :
> 
>     // this is the counter-point to -[CWindow _nativeSetStyleBit:]
>     private void setStyleBits(final int mask, final boolean value) {
>         execute(ptr -> nativeSetNSWindowStyleBits(ptr, mask, value ? mask : 0));
>     }
> 
> After: .. well exactly the same thing .. you just added a RESIZABLE bit that will be ignored.
> 
> It may make a difference in the isFocusable case .. but that does not match what you
> say you are doing.
> 
> -phil.
> 
> On 02/16/2018 08:17 AM, Kevin Rushforth wrote:
>> 
>> > Kindly review the fix for JDK10.
>> 
>> You mean JDK 11, right?
>> 
>> -- Kevin
>> 
>> 
>> Manajit Halder wrote:
>>> 
>>> Hi All,
>>> 
>>> Kindly review the fix for JDK10.
>>> 
>>> Bug: 
>>> https://bugs.openjdk.java.net/browse/JDK-7158623 <https://bugs.openjdk.java.net/browse/JDK-7158623>
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~mhalder/7158623/webrev.00/ <http://cr.openjdk.java.net/%7Emhalder/7158623/webrev.00/>
>>> 
>>> Issue:
>>> Unfocusable frame was resizable.
>>> 
>>> Fix:
>>> After the fix resizability of the frame depends on focusability of the frame. If the frame is focusable then it is resizable otherwise not.
>>> The test code was cleaned to remove old test machinery code.
>>> 
>>> Regards,
>>> Manajit
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/3d5f1127/attachment-0001.html>

From manajit.halder at oracle.com  Mon Feb 26 09:39:28 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 26 Feb 2018 15:09:28 +0530
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
Message-ID: <20523728-C66E-4AE4-8AF1-3640888E31EB@oracle.com>

Looks good. 
+1

Regards,
Manajit

> On 26-Feb-2018, at 10:59 AM, Prem Balakrishnan <prem.balakrishnan at oracle.com> wrote:
> 
> Hi All,
>  
> Please review fix for JDK 11:
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196435 <https://bugs.openjdk.java.net/browse/JDK-8196435>
>  
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196435/webrev.00/ <http://cr.openjdk.java.net/~pkbalakr/8196435/webrev.00/>
>  
> Test fails due to synchronization issue. 
>  
> Regards,
> Prem

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/64051a14/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Mon Feb 26 10:10:34 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara veerabhadraiah)
Date: Mon, 26 Feb 2018 15:40:34 +0530
Subject: <AWT Dev> [11] JDK-8198690: Multiple failures in
 java/awt/Window/ShapedAndTranslucentWindows
Message-ID: <89355B13-9330-4BB6-8CC5-F0B05DB82B9D@oracle.com>

Hi All, Please review a test fix for the following bug:

      Bug: https://bugs.openjdk.java.net/browse/JDK-8198690

      Webrev: http://cr.openjdk.java.net/~sveerabhadra/8198690/webrev.00/

Summary: Certain tests under the folder java/awt/Window/ShapedAndTranslucentWindows fails due to color comparison between expected and actual one. These tests fails only on MacOS. These are the tests that fails for the color comparison:
	1.	java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java
        2.     java/awt/Window/ShapedAndTranslucentWindows/Shaped.java
        3.     java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java

Certain lenience is made for the color comparison logic by adding certain tolerance band for the same. The color difference varies from a value of 5 to 40, hence chosen the maximum out of this difference. I had tried delays and other syncing methods but all fails. Please let me know if there is any better logic to avoid tolerance based color comparison.

Thanks and regards,
Shashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/cfc8ba7a/attachment.html>

From manajit.halder at oracle.com  Mon Feb 26 11:54:33 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 26 Feb 2018 17:24:33 +0530
Subject: <AWT Dev> [11] Review Request: JDK-8171381 Test
 javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X
Message-ID: <520A9D92-37DD-4C35-884F-C6F42D0CA20B@oracle.com>

Hi All,
 
Please review fix for JDK 11
 
Bug: 
	https://bugs.openjdk.java.net/browse/JDK-8171381 <https://bugs.openjdk.java.net/browse/JDK-8171381>
 
Webrev:
	http://cr.openjdk.java.net/~mhalder/8171381/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8171381/webrev.00/>
 
Fix:
	Test failed due to synchronization issue.

Regards,
Manajit
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/95434e1b/attachment.html>

From prasanta.sadhukhan at oracle.com  Mon Feb 26 12:35:34 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Mon, 26 Feb 2018 18:05:34 +0530
Subject: <AWT Dev> [11] RFR JDK-8198693:Update ProblemsList for mac
Message-ID: <3f63ac6c-1a9d-b47f-f4de-c9dda63750d3@oracle.com>

Hi All,

Please review the problem list updation for mac to weed out the test 
that are failing at least once in few iterations.
I tested on mac 10.13.3. With this problem list, the test failures and 
errors are nearly zero apart from 2-3 tests that are failing intermittently.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198693
webrev: http://cr.openjdk.java.net/~psadhukhan/8198693/webrev.00/

Regards
Prasanta

From dmitry.markov at oracle.com  Mon Feb 26 12:55:13 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Mon, 26 Feb 2018 12:55:13 +0000
Subject: <AWT Dev> [11] RFR 8187635: On Windows Swing changes keyboard
 layout on a window activation
Message-ID: <07594A6B-81FC-4432-9468-6CAF2EACBF41@oracle.com>

Hello,

Could you review a fix for jdk11, please?

 bug: https://bugs.openjdk.java.net/browse/JDK-8187635
 webrev: http://cr.openjdk.java.net/~dmarkov/8187635/webrev.00/
 
Problem description:
On Windows platform if AWT/Swing app is inactive (does not have focus) and user changes keyboard layout, the app window will receive the message WM_INPUTLANGCHANGE upon activation. During message processing we do NOT set the following flag g_bUserHasChangedInputLang. So the keyboard layout is switched back by AWT toolkit via WM_AWT_ACTIVATEKEYBOARDLAYOUT event. 

Fix:
It is necessary to set the flag g_bUserHasChangedInputLang during processing of WM_INPUTLANGCHANGE to block execution of activateKeyboardLayout() from AwtToolkit.WndProc().

Testing:
I ran related AWT/Swing regression tests and did not observe any new failures.

Thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/f9f43bc5/attachment.html>

From manajit.halder at oracle.com  Mon Feb 26 13:45:41 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 26 Feb 2018 19:15:41 +0530
Subject: <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
In-Reply-To: <ECF1EC5B-A1AB-46CB-AC02-53923A8EEB3F@oracle.com>
References: <DB89D6AD-022D-4A42-BB27-643C79B9176A@oracle.com>
 <3ed75cf6-2a4a-e5a2-2140-6a5ed42ab8b6@oracle.com>
 <72BD431C-1E76-4270-A8E0-408D6B98439A@oracle.com>
 <ab1bdb7e-2be6-1d57-f7d1-0a8b13a1e4ba@oracle.com>
 <CD0F2B6C-5300-41DD-AED3-15D413D01429@oracle.com>
 <5A870469.9070006@oracle.com>
 <ECF1EC5B-A1AB-46CB-AC02-53923A8EEB3F@oracle.com>
Message-ID: <059B7314-C03E-49A7-A6BA-6D27207DB2D3@oracle.com>

Hi Sergey, Phil and Kevin,

Thank you all for your review comments.

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/ <http://cr.openjdk.java.net/~mhalder/8190767/webrev.03/>

Thanks,
Manajit


> On 17-Feb-2018, at 8:03 AM, Manajit Halder <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>> 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>> 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 <https://bugs.openjdk.java.net/browse/JDK-8190767>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mhalder/8190767/webrev.00/ <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.
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/68a5da62/attachment-0001.html>

From semyon.sadetsky at oracle.com  Mon Feb 26 16:47:14 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 26 Feb 2018 08:47:14 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <94e04514-2c02-4a57-b0f1-063508022355@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
Message-ID: <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>

On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:

> Hi Semyon, Thanks for your review and these questions help us to reach 
> the right requirements.
>
> Without this change, there is different behavior on windows compared 
> to Mac/Linux platforms. Hence this change is required to make the 
> behavior same across the platforms. Since the scroll pane control is 
> not displayed for the SCROLLBARS_NEVER case and if not in the 
> setScrollPosition() then how can the user can move to a different 
> position? Since we used to update/recalculate the scroll pane geometry 
> caused changes to move to a different position other than the 
> setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as 
> the user is unable to control the scrolling movement because neither 
> he can set one setScrollPosition() nor the control is displayed to 
> explicitly set the movement. Hope this answers your question.
>
You need to think once again about two facts I brought in my previous 
message.

1. User still may scroll using mouse wheel even when scrollbars are not 
visible.

2. Visibility of scrollbars doesn't affect the requirement to notify the 
scroll about the scrolled component size changes. If the scrolled 
component was 500x500 in size and its position in the 200x200 viewport 
was (300,300) after the size of the component is changed to 300x300 it 
may not be shown at the same position because the previously visible 
component area doesn't exist anymore and the scroll should be moved to 
(100,100). This should work in the same way regardless the selected 
scrlollbar visibility policy.

--Semyon

> Thanks and regards,
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Saturday, February 24, 2018 2:12 AM
> *To:* Shashidhara Veerabhadraiah 
> <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
> ScrollPane is reset after calling validate()
>
> On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>
>     Hi Semyon, Whenever the container is resized we used to update the
>     scroll pane sizes/geometry regardless of the scroll bar display
>     policies. This resizing make sense for the non SCROLLBARS_NEVER
>     cases as the scroll pane is displayed or needed an update. This
>     additional update posed issues for the SCROLLBARS_NEVER case where
>     we are not supposed to display the scroll pane per the java doc,
>     then why update?
>
>     Scroll pane geometry gets updated in 2 ways, one thro?
>     setScrollPosition() and childResized(). So I derived the
>     conclusion based on the javadoc information that since we don?t
>     display the scroll pane there is no need to update the scroll pane
>     geometry based on the childResized() as it was altering the
>     position already set by the setScrollPosition(). This behavior is
>     same as the other non SCROLLBARS_NEVER mode and setting the scroll
>     bar display to SCROLLBARS_NEVER didn?t made any difference.
>
> The only difference of SCROLLBARS_NEVER from others I got from javadoc 
> is that the scroll bar controls are hidden. So the scrolling itself 
> happens in the same way as in the case of visible scroll bars but it 
> can be only controlled by mouse wheel or programmatically. In my 
> understanding this means that the notification about the scrolled 
> component size changes should happen in the same way as for all other 
> cases. I see no reason for the differentiation that your fix 
> introduces. What will happen if to remove this notification for 
> visible scroll bars modes?
>
> --Semyon
>
>     Thanks and regards,
>     Shashi
>
>     *From:*Semyon Sadetsky
>     *Sent:* Friday, February 23, 2018 10:17 PM
>     *To:* Shashidhara Veerabhadraiah
>     <shashidhara.veerabhadraiah at oracle.com>
>     <mailto:shashidhara.veerabhadraiah at oracle.com>;
>     awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>     *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>     ScrollPane is reset after calling validate()
>
>     On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>
>         Hi Semyon, Thanks for your review comments.
>
>         Here are those different scroll bar pane modes and their
>         description:
>
>         *Modifier and Type*
>
>         	
>
>         *Field*
>
>         	
>
>         *Description*
>
>         |static int|
>
>         	
>
>         *SCROLLBARS_ALWAYS
>         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>
>         	
>
>         Specifies that horizontal/vertical scrollbars should always be
>         shown regardless of the respective sizes of the scrollpane and
>         child.
>
>         |static int|
>
>         	
>
>         *SCROLLBARS_AS_NEEDED
>         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>
>         	
>
>         Specifies that horizontal/vertical scrollbar should be shown
>         only when the size of the child exceeds the size of the
>         scrollpane in the horizontal/vertical dimension.
>
>         |static int|
>
>         	
>
>         *SCROLLBARS_NEVER
>         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>
>         	
>
>         Specifies that horizontal/vertical scrollbars should never be
>         shown regardless of the respective sizes of the scrollpane and
>         child.
>
>     This javadoc, you've copy-pasted here, doesn't explain why in your
>     fix the notification about changed child size is disabled for
>     SCROLLBARS_NEVER case.
>
>         Thanks and regards,
>         Shashi
>
>         *From:*Semyon Sadetsky
>         *Sent:* Thursday, February 22, 2018 11:58 PM
>         *To:* Shashidhara Veerabhadraiah
>         <shashidhara.veerabhadraiah at oracle.com>
>         <mailto:shashidhara.veerabhadraiah at oracle.com>;
>         awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>         *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>         ScrollPane is reset after calling validate()
>
>         Hi Shashi,
>
>         Can you clarify what is the principal difference between
>         SCROLLBARS_NEVER and other scroll policies that requires to
>         avoid updating the scroll geometry according to the inner
>         component size?
>
>         --Semyon
>
>         On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
>
>             Hi All, Please review a code fix for the below bug.
>
>             Bug: https://bugs.openjdk.java.net/browse/JDK-8195738
>
>             Webrev:
>             http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>             <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>
>             Problematic platform: Windows only.
>
>             Summary: This bug occurs only on windows platform and
>             whereas the behavior is different on Mac/Linux platforms.
>             Now after this fix there is common behavior across the
>             platforms.
>
>             The main problem was with resetting the state of the
>             scroll bars even though the scroll bar panes are spawned
>             with SCROLLBARS_NEVER as the scroll bar display policy.
>             This resetting should not occur as the scroll bar display
>             policy makes the
>
>             scroll bar panes invisible. Hence except the
>             setScrollPosition() calls, we don?t need to resize/update
>             the scroll bars state upon calling the scroll bars
>             validation if SCROLLBARS_NEVER policy is used as the
>             scroll bars are not displayed.
>
>             Thanks and regards,
>             Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/8dafae7d/attachment-0001.html>

From semyon.sadetsky at oracle.com  Mon Feb 26 16:53:25 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 26 Feb 2018 08:53:25 -0800
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
Message-ID: <0525807e-0ab4-fb8a-43c3-694d49d984c0@oracle.com>

+1

--Semyon


On 02/25/2018 05:53 PM, Krishna Addepalli wrote:
>
> Hi All,
>
> Please review a fix for JDK-8197808: 
> https://bugs.openjdk.java.net/browse/JDK-8197808
>
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/ 
> <http://cr.openjdk.java.net/%7Ekaddepalli/8197808/webrev00/>
>
> The problem was that by the time Robot tries to read the color on 
> screen, the compositing of the window is not completed, and hence, 
> instead of reading Blue color, it is reading a combination of Blue and 
> Red colors. Increasing the delay by 100 ms made sure that the 
> composition is complete and the color is being read correctly. Also, 
> this happens only on Windows 10.
>
> Apart from this, the test was not cleaning up the windows when it 
> throws exception, so fixed that, and also added all explicit imports.
>
> Thanks,
>
> Krishna
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/4ec56756/attachment.html>

From semyon.sadetsky at oracle.com  Mon Feb 26 17:06:19 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 26 Feb 2018 09:06:19 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
Message-ID: <005ed706-9e10-af99-54aa-b7f23d8cf1aa@oracle.com>

+1

--Semyon


On 02/25/2018 09:29 PM, Prem Balakrishnan wrote:
>
> Hi All,
>
> Please review fix for JDK 11:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196435
>
> Webrev: http://cr.openjdk.java.net/~pkbalakr/8196435/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epkbalakr/8196435/webrev.00/>
>
> Test fails due to synchronization issue.
>
> Regards,
>
> Prem
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/1277bf79/attachment.html>

From semyon.sadetsky at oracle.com  Mon Feb 26 17:11:46 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 26 Feb 2018 09:11:46 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8171381 Test
 javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X
In-Reply-To: <520A9D92-37DD-4C35-884F-C6F42D0CA20B@oracle.com>
References: <520A9D92-37DD-4C35-884F-C6F42D0CA20B@oracle.com>
Message-ID: <4fa89289-d0d5-1628-8a3b-a30a928f6ad7@oracle.com>

+1

--Semyon

On 02/26/2018 03:54 AM, Manajit Halder wrote:
> Hi All,
> Please review fix for JDK 11
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8171381
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8171381/webrev.00/ 
> <http://cr.openjdk.java.net/%7Emhalder/8171381/webrev.00/>
> Fix:
> Test failed due to?synchronization issue.
>
> Regards,
> Manajit

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/0e1ce1ee/attachment.html>

From manajit.halder at oracle.com  Mon Feb 26 17:22:04 2018
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 26 Feb 2018 22:52:04 +0530
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <0525807e-0ab4-fb8a-43c3-694d49d984c0@oracle.com>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <0525807e-0ab4-fb8a-43c3-694d49d984c0@oracle.com>
Message-ID: <AB21497F-44B3-4C80-B32E-E666B8C9D2B3@oracle.com>

Hi Krishna,

Fix looks good. 

I suggest the following changes before committing.
 1) Remove the comma in between the two bug ids.
 2) Is the message ?Test PASSED? required?

Regards,
Manajit


> On 26-Feb-2018, at 10:23 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> +1
> 
> --Semyon
> 
> 
> On 02/25/2018 05:53 PM, Krishna Addepalli wrote:
>> Hi All,
>>  
>> Please review a fix for JDK-8197808: https://bugs.openjdk.java.net/browse/JDK-8197808 <https://bugs.openjdk.java.net/browse/JDK-8197808>
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/ <http://cr.openjdk.java.net/%7Ekaddepalli/8197808/webrev00/>
>>  
>> The problem was that by the time Robot tries to read the color on screen, the compositing of the window is not completed, and hence, instead of reading Blue color, it is reading a combination of Blue and Red colors. Increasing the delay by 100 ms made sure that the composition is complete and the color is being read correctly. Also, this happens only on Windows 10.
>> Apart from this, the test was not cleaning up the windows when it throws exception, so fixed that, and also added all explicit imports.
>>  
>> Thanks,
>> Krishna
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/6f058aa2/attachment-0001.html>

From shashidhara.veerabhadraiah at oracle.com  Mon Feb 26 17:51:47 2018
From: shashidhara.veerabhadraiah at oracle.com (shashidhara veerabhadraiah)
Date: Mon, 26 Feb 2018 23:21:47 +0530
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
Message-ID: <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>

I think I agree Semyon. Thanks for your detailed explanation.

So how do we approach on this? I see a different behaviour on other platforms. Shouldn?t we have a common behaviour across platforms? I agree with your analysis and hence should we change the behaviour on other platforms so that all of them will have the same behaviour?

Thanks and regards,
Shashi

> On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
> 
>> Hi Semyon, Thanks for your review and these questions help us to reach the right requirements. 
>>  
>> Without this change, there is different behavior on windows compared to Mac/Linux platforms. Hence this change is required to make the behavior same across the platforms. Since the scroll pane control is not displayed for the SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the user can move to a different position? Since we used to update/recalculate the scroll pane geometry caused changes to move to a different position other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the user is unable to control the scrolling movement because neither he can set one setScrollPosition() nor the control is displayed to explicitly set the movement. Hope this answers your question.
> You need to think once again about two facts I brought in my previous message.
> 
> 1. User still may scroll using mouse wheel even when scrollbars are not visible.
> 
> 2. Visibility of scrollbars doesn't affect the requirement to notify the scroll about the scrolled component size changes. If the scrolled component was 500x500 in size and its position in the 200x200 viewport was (300,300) after the size of the component is changed to 300x300 it may not be shown at the same position because the previously visible component area doesn't exist anymore and the scroll should be moved to (100,100). This should work in the same way regardless the selected scrlollbar visibility policy.
> 
> --Semyon
> 
>>  
>> Thanks and regards,
>> Shashi
>> ? <>
>> From: Semyon Sadetsky 
>> Sent: Saturday, February 24, 2018 2:12 AM
>> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()
>>  
>> On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>> 
>> Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?
>>  
>> Scroll pane geometry gets updated in 2 ways, one thro? setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don?t display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn?t made any difference.
>> The only difference of SCROLLBARS_NEVER from others I got from javadoc is that the scroll bar controls are hidden. So the scrolling itself happens in the same way as in the case of visible scroll bars but it can be only controlled by mouse wheel or programmatically. In my understanding this means that the notification about the scrolled component size changes should happen in the same way as for all other cases. I see no reason for the differentiation that your fix introduces. What will happen if to remove this notification for visible scroll bars modes?
>> 
>> --Semyon
>> 
>>  
>> Thanks and regards,
>> Shashi
>>  
>> From: Semyon Sadetsky 
>> Sent: Friday, February 23, 2018 10:17 PM
>> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()
>>  
>> On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>> 
>> Hi Semyon, Thanks for your review comments.
>>  
>> Here are those different scroll bar pane modes and their description:
>> Modifier and Type
>> Field
>> Description
>> static int
>> SCROLLBARS_ALWAYS <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>	
>> Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.
>> static int
>> SCROLLBARS_AS_NEEDED <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>	
>> Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.
>> static int
>> SCROLLBARS_NEVER <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>	
>> Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.
>>  
>> This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case.
>> Thanks and regards,
>> Shashi
>>  
>> From: Semyon Sadetsky 
>> Sent: Thursday, February 22, 2018 11:58 PM
>> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> <mailto:shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
>> Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()
>>  
>> Hi Shashi,
>> 
>> Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?
>> 
>> --Semyon
>> 
>> On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a code fix for the below bug.
>>  
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195738 <https://bugs.openjdk.java.net/browse/JDK-8195738>
>>  
>> Webrev: http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/ <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>>  
>> Problematic platform: Windows only.
>>  
>> Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.
>> The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the 
>> scroll bar panes invisible. Hence except the setScrollPosition() calls, we don?t need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.
>>  
>> Thanks and regards,
>> Shashi
>>  
>>  
>>  
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/e122d546/attachment-0001.html>

From philip.race at oracle.com  Mon Feb 26 18:55:29 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 26 Feb 2018 10:55:29 -0800
Subject: <AWT Dev> [11] RFR JDK-8198693:Update ProblemsList for mac
In-Reply-To: <3f63ac6c-1a9d-b47f-f4de-c9dda63750d3@oracle.com>
References: <3f63ac6c-1a9d-b47f-f4de-c9dda63750d3@oracle.com>
Message-ID: <15e7ef55-1da1-a1fd-5008-ab6b355aeb2f@oracle.com>

+1 .. good to get these mac issues problem listed.

-phil.

On 2/26/2018 4:35 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> Please review the problem list updation for mac to weed out the test 
> that are failing at least once in few iterations.
> I tested on mac 10.13.3. With this problem list, the test failures and 
> errors are nearly zero apart from 2-3 tests that are failing 
> intermittently.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198693
> webrev: http://cr.openjdk.java.net/~psadhukhan/8198693/webrev.00/
>
> Regards
> Prasanta



From Sergey.Bylokhov at oracle.com  Mon Feb 26 19:45:12 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 11:45:12 -0800
Subject: <AWT Dev> <Swing Dev> [11] RFR JDK-8198693:Update ProblemsList
 for mac
In-Reply-To: <15e7ef55-1da1-a1fd-5008-ab6b355aeb2f@oracle.com>
References: <3f63ac6c-1a9d-b47f-f4de-c9dda63750d3@oracle.com>
 <15e7ef55-1da1-a1fd-5008-ab6b355aeb2f@oracle.com>
Message-ID: <1527c31d-ae6c-0bdb-0e9b-3e7984bc8cca@oracle.com>

Hi, Prasanta.
Looks fine.
But please add a comment to each bug that the test fails on macos, an 
example:
+ java/awt/Focus/ChoiceFocus/ChoiceFocus.java 8169103 windows-all,macosx-all

https://bugs.openjdk.java.net/browse/JDK-8169103
"This issue was not observed on Linux, OSX "

On 26/02/2018 10:55, Phil Race wrote:
> +1 .. good to get these mac issues problem listed.
> 
> -phil.
> 
> On 2/26/2018 4:35 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>>
>> Please review the problem list updation for mac to weed out the test 
>> that are failing at least once in few iterations.
>> I tested on mac 10.13.3. With this problem list, the test failures and 
>> errors are nearly zero apart from 2-3 tests that are failing 
>> intermittently.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198693
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8198693/webrev.00/
>>
>> Regards
>> Prasanta
> 
> 


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Mon Feb 26 19:51:36 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 26 Feb 2018 11:51:36 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
Message-ID: <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>

The bug was failed against Windows platform. So, I'd try to find the 
root cause why when the scroll is notified with the scrolled component 
size the scroll position is set to the wrong value.

--Semyon


On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
> I think I agree Semyon. Thanks for your detailed explanation.
>
> So how do we approach on this? I see a different behaviour on other 
> platforms. Shouldn?t we have a common behaviour across platforms? I 
> agree with your analysis and hence should we change the behaviour on 
> other platforms so that all of them will have the same behaviour?
>
> Thanks and regards,
> Shashi
>
>> On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>>
>>> Hi Semyon, Thanks for your review and these questions help us to 
>>> reach the right requirements.
>>> Without this change, there is different behavior on windows compared 
>>> to Mac/Linux platforms. Hence this change is required to make the 
>>> behavior same across the platforms. Since the scroll pane control is 
>>> not displayed for the SCROLLBARS_NEVER case and if not in the 
>>> setScrollPosition() then how can the user can move to a different 
>>> position? Since we used to update/recalculate the scroll pane 
>>> geometry caused changes to move to a different position other than 
>>> the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as 
>>> unusable as the user is unable to control the scrolling movement 
>>> because neither he can set one setScrollPosition() nor the control 
>>> is displayed to explicitly set the movement. Hope this answers your 
>>> question.
>> You need to think once again about two facts I brought in my previous 
>> message.
>>
>> 1. User still may scroll using mouse wheel even when scrollbars are 
>> not visible.
>>
>> 2. Visibility of scrollbars doesn't affect the requirement to notify 
>> the scroll about the scrolled component size changes. If the scrolled 
>> component was 500x500 in size and its position in the 200x200 
>> viewport was (300,300) after the size of the component is changed to 
>> 300x300 it may not be shown at the same position because the 
>> previously visible component area doesn't exist anymore and the 
>> scroll should be moved to (100,100). This should work in the same way 
>> regardless the selected scrlollbar visibility policy.
>>
>> --Semyon
>>
>>> Thanks and regards,
>>> Shashi
>>> *From:*Semyon Sadetsky
>>> *Sent:*Saturday, February 24, 2018 2:12 AM
>>> *To:*Shashidhara 
>>> Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>> *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
>>> ScrollPane is reset after calling validate()
>>>
>>> On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>>>
>>>     Hi Semyon, Whenever the container is resized we used to update
>>>     the scroll pane sizes/geometry regardless of the scroll bar
>>>     display policies. This resizing make sense for the non
>>>     SCROLLBARS_NEVER cases as the scroll pane is displayed or needed
>>>     an update. This additional update posed issues for the
>>>     SCROLLBARS_NEVER case where we are not supposed to display the
>>>     scroll pane per the java doc, then why update?
>>>     Scroll pane geometry gets updated in 2 ways, one thro?
>>>     setScrollPosition() and childResized(). So I derived the
>>>     conclusion based on the javadoc information that since we don?t
>>>     display the scroll pane there is no need to update the scroll
>>>     pane geometry based on the childResized() as it was altering the
>>>     position already set by the setScrollPosition(). This behavior
>>>     is same as the other non SCROLLBARS_NEVER mode and setting the
>>>     scroll bar display to SCROLLBARS_NEVER didn?t made any difference.
>>>
>>> The only difference of SCROLLBARS_NEVER from others I got from 
>>> javadoc is that the scroll bar controls are hidden. So the scrolling 
>>> itself happens in the same way as in the case of visible scroll bars 
>>> but it can be only controlled by mouse wheel or programmatically. In 
>>> my understanding this means that the notification about the scrolled 
>>> component size changes should happen in the same way as for all 
>>> other cases. I see no reason for the differentiation that your fix 
>>> introduces. What will happen if to remove this notification for 
>>> visible scroll bars modes?
>>>
>>> --Semyon
>>>
>>>     Thanks and regards,
>>>     Shashi
>>>     *From:*Semyon Sadetsky
>>>     *Sent:*Friday, February 23, 2018 10:17 PM
>>>     *To:*Shashidhara
>>>     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>>     <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>>     <mailto:awt-dev at openjdk.java.net>
>>>     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>>     ScrollPane is reset after calling validate()
>>>
>>>     On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>>>
>>>         Hi Semyon, Thanks for your review comments.
>>>         Here are those different scroll bar pane modes and their
>>>         description:
>>>         *Modifier and Type*
>>>         	
>>>         *Field*
>>>         	
>>>         *Description*
>>>         |static int|
>>>         	
>>>         *SCROLLBARS_ALWAYS
>>>         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>>>         	
>>>         Specifies that horizontal/vertical scrollbars should always
>>>         be shown regardless of the respective sizes of the
>>>         scrollpane and child.
>>>         |static int|
>>>         	
>>>         *SCROLLBARS_AS_NEEDED
>>>         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>>>         	
>>>         Specifies that horizontal/vertical scrollbar should be shown
>>>         only when the size of the child exceeds the size of the
>>>         scrollpane in the horizontal/vertical dimension.
>>>         |static int|
>>>         	
>>>         *SCROLLBARS_NEVER
>>>         <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>>>         	
>>>         Specifies that horizontal/vertical scrollbars should never
>>>         be shown regardless of the respective sizes of the
>>>         scrollpane and child.
>>>
>>>     This javadoc, you've copy-pasted here, doesn't explain why in
>>>     your fix the notification about changed child size is disabled
>>>     for SCROLLBARS_NEVER case.
>>>
>>>         Thanks and regards,
>>>         Shashi
>>>         *From:*Semyon Sadetsky
>>>         *Sent:*Thursday, February 22, 2018 11:58 PM
>>>         *To:*Shashidhara
>>>         Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>>>         <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>>>         <mailto:awt-dev at openjdk.java.net>
>>>         *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion in
>>>         ScrollPane is reset after calling validate()
>>>
>>>         Hi Shashi,
>>>
>>>         Can you clarify what is the principal difference between
>>>         SCROLLBARS_NEVER and other scroll policies that requires to
>>>         avoid updating the scroll geometry according to the inner
>>>         component size?
>>>
>>>         --Semyon
>>>
>>>         On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:
>>>
>>>             Hi All, Please review a code fix for the below bug.
>>>             Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>>>             Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>>>             <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>>>             Problematic platform: Windows only.
>>>             Summary: This bug occurs only on windows platform and
>>>             whereas the behavior is different on Mac/Linux
>>>             platforms. Now after this fix there is common behavior
>>>             across the platforms.
>>>             The main problem was with resetting the state of the
>>>             scroll bars even though the scroll bar panes are spawned
>>>             with SCROLLBARS_NEVER as the scroll bar display policy.
>>>             This resetting should not occur as the scroll bar
>>>             display policy makes the
>>>             scroll bar panes invisible. Hence except the
>>>             setScrollPosition() calls, we don?t need to
>>>             resize/update the scroll bars state upon calling the
>>>             scroll bars validation if SCROLLBARS_NEVER policy is
>>>             used as the scroll bars are not displayed.
>>>             Thanks and regards,
>>>             Shashi
>>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/dc4580b4/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Mon Feb 26 22:16:06 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 14:16:06 -0800
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
Message-ID: <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>

Hi, Krishna.
This test was added to the problemlist, please check that it works on 
other platforms and remove it from the problemlist.

On 25/02/2018 17:53, Krishna Addepalli wrote:
> Hi All,
> 
> Please review a fix for JDK-8197808: 
> https://bugs.openjdk.java.net/browse/JDK-8197808
> 
> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/
> 
> The problem was that by the time Robot tries to read the color on 
> screen, the compositing of the window is not completed, and hence, 
> instead of reading Blue color, it is reading a combination of Blue and 
> Red colors. Increasing the delay by 100 ms made sure that the 
> composition is complete and the color is being read correctly. Also, 
> this happens only on Windows 10.
> 
> Apart from this, the test was not cleaning up the windows when it throws 
> exception, so fixed that, and also added all explicit imports.
> 
> Thanks,
> 
> Krishna
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Feb 26 22:21:23 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 14:21:23 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8171381 Test
 javax/swing/JPopupMenu/7156657/bug7156657.java fails on OS X
In-Reply-To: <520A9D92-37DD-4C35-884F-C6F42D0CA20B@oracle.com>
References: <520A9D92-37DD-4C35-884F-C6F42D0CA20B@oracle.com>
Message-ID: <4c7acf41-0a86-6b07-55fc-1b19303a2039@oracle.com>

Hi, Manajit.
Can you please clarify what synchronization issue was fixed? It is 
unclear because robot.waitForIdle() is implemented using realSync().

On 26/02/2018 03:54, Manajit Halder wrote:
> Hi All,
> Please review fix for JDK 11
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8171381
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8171381/webrev.00/
> Fix:
> Test failed due to?synchronization issue.
> 
> Regards,
> Manajit


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Feb 26 22:28:42 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 14:28:42 -0800
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
Message-ID: <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>

Hi, Prem.
> Test fails due to synchronization issue.

Can you please clarify what synchronization issue was fixed? The code 
before/after mostly identical except xxx.setResizable(false);


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Feb 26 22:35:27 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 14:35:27 -0800
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>
References: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>
Message-ID: <b158767b-ebe2-9bfe-ce6b-2dc3bc3ee7a3@oracle.com>

Hi, Shashi.
Why this test should be platform specific? It shows two common frames 
and use some generic api for mouse events.
This test also was updated in JDK-8027154 and I assume it should works 
on macOS after that, maybe we have a new regression here?

On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review a test fix for the below bug:
> 
>  ??????? Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
> 
>  ??????? Webrev: http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
> 
> Summary: The original bug 
> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only for 
> MacOS platform but the test is enabled to run on all platforms. This is 
> modified. Along with it exact positional comparison was done in the test 
> and now modified to allow for leniency of around 2 pixels.
> 
> Thanks and regards,
> Shashi
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Feb 26 22:43:24 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 14:43:24 -0800
Subject: <AWT Dev> [11] RFR 8187635: On Windows Swing changes keyboard
 layout on a window activation
In-Reply-To: <07594A6B-81FC-4432-9468-6CAF2EACBF41@oracle.com>
References: <07594A6B-81FC-4432-9468-6CAF2EACBF41@oracle.com>
Message-ID: <bfa6eef7-b426-2bf1-2194-1cd2bf50db00@oracle.com>

Looks fine.

On 26/02/2018 04:55, Dmitry Markov wrote:
> Hello,
> 
> Could you review a fix for jdk11, please?
> 
>  ?bug: https://bugs.openjdk.java.net/browse/JDK-8187635
>  ?webrev: http://cr.openjdk.java.net/~dmarkov/8187635/webrev.00/
> 
> Problem description:
> On Windows platform if AWT/Swing app is inactive (does not have focus) 
> and user changes keyboard layout, the app window will receive the 
> message WM_INPUTLANGCHANGE upon activation. During message processing we 
> do NOT set the following flag g_bUserHasChangedInputLang. So the 
> keyboard layout is switched back by AWT toolkit via 
> WM_AWT_ACTIVATEKEYBOARDLAYOUT event.
> 
> Fix:
> It is necessary to set the flag g_bUserHasChangedInputLang during 
> processing of WM_INPUTLANGCHANGE to block execution of 
> activateKeyboardLayout() from AwtToolkit.WndProc().
> 
> Testing:
> I ran related AWT/Swing regression tests and did not observe any new 
> failures.
> 
> Thanks,
> Dmitry


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Feb 26 23:40:56 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Feb 2018 15:40:56 -0800
Subject: <AWT Dev> [11] JDK-8198690: Multiple failures in
 java/awt/Window/ShapedAndTranslucentWindows
In-Reply-To: <89355B13-9330-4BB6-8CC5-F0B05DB82B9D@oracle.com>
References: <89355B13-9330-4BB6-8CC5-F0B05DB82B9D@oracle.com>
Message-ID: <05e68b35-7a92-893d-16a4-e5b773505a51@oracle.com>

Hi, Shashi.
> Please let me know if there is any better logic to avoid tolerance based color comparison.
The difference between Color(0, 0, 255) used by the background frame and 
the Color(0, 0, ~216) captured by the robot is quite big.
I guess the difference should be visible by the user, but if I am not 
missed something the window really draw color_blue=255, why the robot 
capture wrong color?

-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 27 00:19:34 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Feb 2018 16:19:34 -0800
Subject: <AWT Dev> [11] JDK-8198690: Multiple failures in
	java/awt/Window/ShapedAndTranslucentWindows
In-Reply-To: <05e68b35-7a92-893d-16a4-e5b773505a51@oracle.com>
References: <89355B13-9330-4BB6-8CC5-F0B05DB82B9D@oracle.com>
 <05e68b35-7a92-893d-16a4-e5b773505a51@oracle.com>
Message-ID: <5A94A416.5030600@oracle.com>

I think you need to use Image I/O to save the failed image and examine it.
The test is capturing pixels at offsets of 20 into the window, 
presumably to avoid
any "nice" blending effects the desktop may apply to the edges of windows.
If you save the image you can inspect it at leisure better assess why 
the test fails.
The StaticallyShaped one for example carves out rectangles and maybe on 
MacOS
the blending is happening on these too ?

-phil.

On 2/26/18, 3:40 PM, Sergey Bylokhov wrote:
> Hi, Shashi.
>> Please let me know if there is any better logic to avoid tolerance 
>> based color comparison.
> The difference between Color(0, 0, 255) used by the background frame 
> and the Color(0, 0, ~216) captured by the robot is quite big.
> I guess the difference should be visible by the user, but if I am not 
> missed something the window really draw color_blue=255, why the robot 
> capture wrong color?
>

From philip.race at oracle.com  Tue Feb 27 00:31:05 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Feb 2018 16:31:05 -0800
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>
Message-ID: <5A94A6C9.6060109@oracle.com>

Yes .. even if bugs were added to the problem list in bulk, the 
expectation is that
they'll be removed by the bug fix that fixes the failure.
And if it still fails on some platforms then either (1) you aren't done 
with your fix, or (2)
you need to find a different bug ID under which to now exclude the test for
the platform(s) that still fail for what would normally be some 
completely un-related reason.

Other than that the fix is fine.

-phil.

On 2/26/18, 2:16 PM, Sergey Bylokhov wrote:
> Hi, Krishna.
> This test was added to the problemlist, please check that it works on 
> other platforms and remove it from the problemlist.
>
> On 25/02/2018 17:53, Krishna Addepalli wrote:
>> Hi All,
>>
>> Please review a fix for JDK-8197808: 
>> https://bugs.openjdk.java.net/browse/JDK-8197808
>>
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/
>>
>> The problem was that by the time Robot tries to read the color on 
>> screen, the compositing of the window is not completed, and hence, 
>> instead of reading Blue color, it is reading a combination of Blue 
>> and Red colors. Increasing the delay by 100 ms made sure that the 
>> composition is complete and the color is being read correctly. Also, 
>> this happens only on Windows 10.
>>
>> Apart from this, the test was not cleaning up the windows when it 
>> throws exception, so fixed that, and also added all explicit imports.
>>
>> Thanks,
>>
>> Krishna
>>
>
>

From philip.race at oracle.com  Tue Feb 27 00:32:36 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Feb 2018 16:32:36 -0800
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <AB21497F-44B3-4C80-B32E-E666B8C9D2B3@oracle.com>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <0525807e-0ab4-fb8a-43c3-694d49d984c0@oracle.com>
 <AB21497F-44B3-4C80-B32E-E666B8C9D2B3@oracle.com>
Message-ID: <5A94A724.6090908@oracle.com>



On 2/26/18, 9:22 AM, Manajit Halder wrote:
> Hi Krishna,
>
> Fix looks good.
>
> I suggest the following changes before committing.
>  1) Remove the comma in between the two bug ids.
yes .. not sure if jtreg cares though.
>  2) Is the message ?Test PASSED? required?

I find these statements useful .. silence doesn't tell you that it is 
done or succeeded.

-phil.
>
> Regards,
> Manajit
>
>
>> On 26-Feb-2018, at 10:23 PM, Semyon Sadetsky 
>> <semyon.sadetsky at oracle.com <mailto:semyon.sadetsky at oracle.com>> wrote:
>>
>> +1
>>
>> --Semyon
>>
>>
>> On 02/25/2018 05:53 PM, Krishna Addepalli wrote:
>>> Hi All,
>>> Please review a fix for 
>>> JDK-8197808:https://bugs.openjdk.java.net/browse/JDK-8197808
>>> Webrev:http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/ 
>>> <http://cr.openjdk.java.net/%7Ekaddepalli/8197808/webrev00/>
>>> The problem was that by the time Robot tries to read the color on 
>>> screen, the compositing of the window is not completed, and hence, 
>>> instead of reading Blue color, it is reading a combination of Blue 
>>> and Red colors. Increasing the delay by 100 ms made sure that the 
>>> composition is complete and the color is being read correctly. Also, 
>>> this happens only on Windows 10.
>>> Apart from this, the test was not cleaning up the windows when it 
>>> throws exception, so fixed that, and also added all explicit imports.
>>> Thanks,
>>> Krishna
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180226/3cfed29b/attachment.html>

From shashidhara.veerabhadraiah at oracle.com  Tue Feb 27 04:11:23 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 26 Feb 2018 20:11:23 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <b158767b-ebe2-9bfe-ce6b-2dc3bc3ee7a3@oracle.com>
References: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>
 <b158767b-ebe2-9bfe-ce6b-2dc3bc3ee7a3@oracle.com>
Message-ID: <2ec8f1fa-b832-43a4-a507-1f6af9d2474a@default>

Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.

We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.

Thanks and regards,
Shashi

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, February 27, 2018 4:05 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

Hi, Shashi.
Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?

On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
> Hi All, Please review a test fix for the below bug:
> 
>  ??????? Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
> 
>  ??????? Webrev: 
> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
> 
> Summary: The original bug
> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
> for MacOS platform but the test is enabled to run on all platforms. 
> This is modified. Along with it exact positional comparison was done 
> in the test and now modified to allow for leniency of around 2 pixels.
> 
> Thanks and regards,
> Shashi
> 


--
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 27 04:42:11 2018
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Feb 2018 20:42:11 -0800
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <2ec8f1fa-b832-43a4-a507-1f6af9d2474a@default>
References: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>
 <b158767b-ebe2-9bfe-ce6b-2dc3bc3ee7a3@oracle.com>
 <2ec8f1fa-b832-43a4-a507-1f6af9d2474a@default>
Message-ID: <5A94E1A3.5020705@oracle.com>

What Windows 10 version are you running ? As discussed a few times ... 
probably off-list ..
there is a bug in Windows 10 Fall Creators (build 1709) that breaks 
mouse moves.

-phil.

On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>
> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, February 27, 2018 4:05 AM
> To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re:<AWT Dev>  [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
>
> Hi, Shashi.
> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>
> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a test fix for the below bug:
>>
>>           Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>
>>           Webrev:
>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>
>> Summary: The original bug
>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only
>> for MacOS platform but the test is enabled to run on all platforms.
>> This is modified. Along with it exact positional comparison was done
>> in the test and now modified to allow for leniency of around 2 pixels.
>>
>> Thanks and regards,
>> Shashi
>>
>
> --
> Best regards, Sergey.

From shashidhara.veerabhadraiah at oracle.com  Tue Feb 27 04:45:31 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Mon, 26 Feb 2018 20:45:31 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <5A94E1A3.5020705@oracle.com>
References: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>
 <b158767b-ebe2-9bfe-ce6b-2dc3bc3ee7a3@oracle.com>
 <2ec8f1fa-b832-43a4-a507-1f6af9d2474a@default> <5A94E1A3.5020705@oracle.com>
Message-ID: <1a170b63-391b-416d-9cc2-4e66e2a63a76@default>

Am using Windows 10 Pro    Version: 1703!! Do you suspect this has those specific mouse move issues?

Thanks and regards,
Shashi

-----Original Message-----
From: Philip Race 
Sent: Tuesday, February 27, 2018 10:12 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

What Windows 10 version are you running ? As discussed a few times ... 
probably off-list ..
there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.

-phil.

On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>
> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, February 27, 2018 4:05 AM
> To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re:<AWT Dev>  [11] JDK-8196017: 
> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java 
> fails
>
> Hi, Shashi.
> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>
> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a test fix for the below bug:
>>
>>           Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>
>>           Webrev:
>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>
>> Summary: The original bug
>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
>> for MacOS platform but the test is enabled to run on all platforms.
>> This is modified. Along with it exact positional comparison was done 
>> in the test and now modified to allow for leniency of around 2 pixels.
>>
>> Thanks and regards,
>> Shashi
>>
>
> --
> Best regards, Sergey.

From prem.balakrishnan at oracle.com  Tue Feb 27 05:20:49 2018
From: prem.balakrishnan at oracle.com (Prem Balakrishnan)
Date: Mon, 26 Feb 2018 21:20:49 -0800 (PST)
Subject: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated
 Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
 fails
In-Reply-To: <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
References: <1fe3ec6e-c506-4556-830f-75f3a1805ec8@default>
 <5492eed4-9950-fa2a-2e69-1e2467aa71aa@oracle.com>
Message-ID: <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd@default>

Hi Sergey,

At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false. 

Regards,
Prem

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, February 27, 2018 3:59 AM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails

Hi, Prem.
> Test fails due to synchronization issue.

Can you please clarify what synchronization issue was fixed? The code before/after mostly identical except xxx.setResizable(false);


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 27 05:45:18 2018
From: philip.race at oracle.com (Phil Race)
Date: Mon, 26 Feb 2018 21:45:18 -0800
Subject: <AWT Dev> [11] JDK-8196017:
	java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
	fails
In-Reply-To: <1a170b63-391b-416d-9cc2-4e66e2a63a76@default>
References: <735df7c3-d6a4-481d-88b2-1bd8e613802e@default>
 <b158767b-ebe2-9bfe-ce6b-2dc3bc3ee7a3@oracle.com>
 <2ec8f1fa-b832-43a4-a507-1f6af9d2474a@default> <5A94E1A3.5020705@oracle.com>
 <1a170b63-391b-416d-9cc2-4e66e2a63a76@default>
Message-ID: <B9523A46-3CFE-455F-A802-0F174C4ADB13@oracle.com>

Could be that it acquired the same bug via a patch release.

-Phil.

> On Feb 26, 2018, at 8:45 PM, Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> wrote:
> 
> Am using Windows 10 Pro    Version: 1703!! Do you suspect this has those specific mouse move issues?
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Philip Race 
> Sent: Tuesday, February 27, 2018 10:12 AM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
> 
> What Windows 10 version are you running ? As discussed a few times ... 
> probably off-list ..
> there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.
> 
> -phil.
> 
>> On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
>> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>> 
>> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>> 
>> Thanks and regards,
>> Shashi
>> 
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 27, 2018 4:05 AM
>> To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re:<AWT Dev>  [11] JDK-8196017: 
>> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java 
>> fails
>> 
>> Hi, Shashi.
>> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
>> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>> 
>>> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test fix for the below bug:
>>> 
>>>          Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>> 
>>>          Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>> 
>>> Summary: The original bug
>>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
>>> for MacOS platform but the test is enabled to run on all platforms.
>>> This is modified. Along with it exact positional comparison was done 
>>> in the test and now modified to allow for leniency of around 2 pixels.
>>> 
>>> Thanks and regards,
>>> Shashi
>>> 
>> 
>> --
>> Best regards, Sergey.


From shashidhara.veerabhadraiah at oracle.com  Tue Feb 27 08:45:26 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 27 Feb 2018 00:45:26 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
Message-ID: <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>

Hi Semyon, Thanks for your help. I did some debugging from that perspective and could find the problem and the solution. Here is the new webrev, please review it:

?

http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/

?

The problem was that in the case of SCROLLBARS_NEVER, scroll bar info was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). This forced the windows to pick a default value and hence reset it to that value every time. Now the logic is modified in a very similar fashion as the other scroll bar display modes but without displaying it using the new win api ShowScrollBar(). The scroll bar info is supplied with a proper range per the corresponding base component but without the scroll bar pane size(as we don?t display it). This should suffice a good range for the scroll bars to operate and correct itself if there is any out of range value is supplied.

?

Thanks and regards,
Shashi

?

From: Semyon Sadetsky 
Sent: Tuesday, February 27, 2018 1:22 AM
To: shashidhara veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

The bug was failed against Windows platform. So, I'd try to find the root cause why when the scroll is notified with the scrolled component size the scroll position is set to the wrong value.

--Semyon

?

On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:

I think I agree Semyon. Thanks for your detailed explanation. 

?

So how do we approach on this? I see a different behaviour on other platforms. Shouldn?t we have a common behaviour across platforms? I agree with your analysis and hence should we change the behaviour on other platforms so that all of them will have the same behaviour?

?

Thanks and regards,

Shashi

?

On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com> wrote:

?

On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review and these questions help us to reach the right requirements.?

?

Without this change, there is different behavior on windows compared to Mac/Linux platforms. Hence this change is required to make the behavior same across the platforms. Since the scroll pane control is not displayed for the SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the user can move to a different position? Since we used to update/recalculate the scroll pane geometry caused changes to move to a different position other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the user is unable to control the scrolling movement because neither he can set one setScrollPosition() nor the control is displayed to explicitly set the movement. Hope this answers your question.

You need to think once again about two facts I brought in my previous message.

1. User still may scroll using mouse wheel even when scrollbars are not visible.

2. Visibility of scrollbars doesn't affect the requirement to notify the scroll about the scrolled component size changes. If the scrolled component was 500x500 in size and its position in the 200x200 viewport was (300,300) after the size of the component is changed to 300x300 it may not be shown at the same position because the previously visible component area doesn't exist anymore and the scroll should be moved to (100,100). This should work in the same way regardless the selected scrlollbar visibility policy.

--Semyon




?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Saturday, February 24, 2018 2:12 AM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?

?

Scroll pane geometry gets updated in 2 ways, one thro? setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don?t display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn?t made any difference.

The only difference of SCROLLBARS_NEVER from others I got from javadoc is that the scroll bar controls are hidden. So the scrolling itself happens in the same way as in the case of visible scroll bars but it can be only controlled by mouse wheel or programmatically. In my understanding this means that the notification about the scrolled component size changes should happen in the same way as for all other cases. I see no reason for the differentiation that your fix introduces. What will happen if to remove this notification for visible scroll bars modes?

--Semyon




?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Friday, February 23, 2018 10:17 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review comments.

?

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

?

This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case.

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Thursday, February 22, 2018 11:58 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

?

Bug:?https://bugs.openjdk.java.net/browse/JDK-8195738

?

Webrev:?HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

?

Problematic platform: Windows only.

?

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the?

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don?t need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

?

Thanks and regards,
Shashi

?

?

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180227/6d746987/attachment-0001.html>

From krishna.addepalli at oracle.com  Tue Feb 27 14:19:33 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 27 Feb 2018 06:19:33 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
Message-ID: <b01398ea-f7c1-41a4-8845-20c0da99eccd@default>


Hi Shashi,

This test passes for me without any problems on my machine. I'm using Windows 10 build 1703 - i.e it is not Fall Creators build.

Also, the intent of the test is to check that, if a frame is drawn on top of another frame, then the mouse move should be seen by the top frame and not the bottom frame. Since we use Robot.mouseMove, I guess it should move to the exact location that we specify.
Frame2 is created at position (120,120). The mouse is moved to (149, 149) first and then to (150,150). So, effectively, mouse position should be (30,30) wrt second frame. I don't see a reason for adding some sort of threshold here like your fix suggests.
And also, since Frame2 is on top, frame2 should see the MouseMove, whereas Frame1 shouldnot see it.

There was a test bug JDK- 8027154, where a fix was done.

Thanks,
Krishna

Message: 1
Date: Mon, 26 Feb 2018 20:45:31 -0800 (PST)
From: Shashidhara Veerabhadraiah
	<shashidhara.veerabhadraiah at oracle.com>
To: Philip Race <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017:
	java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
	fails
Message-ID: <1a170b63-391b-416d-9cc2-4e66e2a63a76 at default>
Content-Type: text/plain; charset=us-ascii

Am using Windows 10 Pro    Version: 1703!! Do you suspect this has those specific mouse move issues?

Thanks and regards,
Shashi

-----Original Message-----
From: Philip Race
Sent: Tuesday, February 27, 2018 10:12 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

What Windows 10 version are you running ? As discussed a few times ... 
probably off-list ..
there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.

-phil.

On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>
> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, February 27, 2018 4:05 AM
> To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>;
> awt-dev at openjdk.java.net
> Subject: Re:<AWT Dev>  [11] JDK-8196017: 
> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
> fails
>
> Hi, Shashi.
> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>
> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a test fix for the below bug:
>>
>>           Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>
>>           Webrev:
>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>
>> Summary: The original bug
>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
>> for MacOS platform but the test is enabled to run on all platforms.
>> This is modified. Along with it exact positional comparison was done 
>> in the test and now modified to allow for leniency of around 2 pixels.
>>
>> Thanks and regards,
>> Shashi
>>
>
> --
> Best regards, Sergey.


------------------------------

Message: 2
Date: Mon, 26 Feb 2018 21:20:49 -0800 (PST)
From: Prem Balakrishnan <prem.balakrishnan at oracle.com>
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>,
	awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression
	automated Test
	'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
	fails
Message-ID: <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd at default>
Content-Type: text/plain; charset=us-ascii

Hi Sergey,

At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false. 

Regards,
Prem

-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, February 27, 2018 3:59 AM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails

Hi, Prem.
> Test fails due to synchronization issue.

Can you please clarify what synchronization issue was fixed? The code before/after mostly identical except xxx.setResizable(false);


--
Best regards, Sergey.


------------------------------

Message: 3
Date: Mon, 26 Feb 2018 21:45:18 -0800
From: Phil Race <philip.race at oracle.com>
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017:
	java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
	fails
Message-ID: <B9523A46-3CFE-455F-A802-0F174C4ADB13 at oracle.com>
Content-Type: text/plain;	charset=us-ascii

Could be that it acquired the same bug via a patch release.

-Phil.

> On Feb 26, 2018, at 8:45 PM, Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> wrote:
> 
> Am using Windows 10 Pro    Version: 1703!! Do you suspect this has those specific mouse move issues?
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Philip Race 
> Sent: Tuesday, February 27, 2018 10:12 AM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
> 
> What Windows 10 version are you running ? As discussed a few times ... 
> probably off-list ..
> there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.
> 
> -phil.
> 
>> On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
>> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>> 
>> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>> 
>> Thanks and regards,
>> Shashi
>> 
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 27, 2018 4:05 AM
>> To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>; 
>> awt-dev at openjdk.java.net
>> Subject: Re:<AWT Dev>  [11] JDK-8196017: 
>> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java 
>> fails
>> 
>> Hi, Shashi.
>> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
>> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>> 
>>> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test fix for the below bug:
>>> 
>>>          Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>> 
>>>          Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>> 
>>> Summary: The original bug
>>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
>>> for MacOS platform but the test is enabled to run on all platforms.
>>> This is modified. Along with it exact positional comparison was done 
>>> in the test and now modified to allow for leniency of around 2 pixels.
>>> 
>>> Thanks and regards,
>>> Shashi
>>> 
>> 
>> --
>> Best regards, Sergey.



------------------------------

Message: 4
Date: Tue, 27 Feb 2018 00:45:26 -0800 (PST)
From: Shashidhara Veerabhadraiah
	<shashidhara.veerabhadraiah at oracle.com>
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane
	is reset after calling validate()
Message-ID: <f88ed3d5-92fd-4a09-81d2-5b1f768b4459 at default>
Content-Type: text/plain; charset="utf-8"

Hi Semyon, Thanks for your help. I did some debugging from that perspective and could find the problem and the solution. Here is the new webrev, please review it:

?

http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/

?

The problem was that in the case of SCROLLBARS_NEVER, scroll bar info was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). This forced the windows to pick a default value and hence reset it to that value every time. Now the logic is modified in a very similar fashion as the other scroll bar display modes but without displaying it using the new win api ShowScrollBar(). The scroll bar info is supplied with a proper range per the corresponding base component but without the scroll bar pane size(as we don?t display it). This should suffice a good range for the scroll bars to operate and correct itself if there is any out of range value is supplied.

?

Thanks and regards,
Shashi

?

From: Semyon Sadetsky 
Sent: Tuesday, February 27, 2018 1:22 AM
To: shashidhara veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

The bug was failed against Windows platform. So, I'd try to find the root cause why when the scroll is notified with the scrolled component size the scroll position is set to the wrong value.

--Semyon

?

On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:

I think I agree Semyon. Thanks for your detailed explanation. 

?

So how do we approach on this? I see a different behaviour on other platforms. Shouldn?t we have a common behaviour across platforms? I agree with your analysis and hence should we change the behaviour on other platforms so that all of them will have the same behaviour?

?

Thanks and regards,

Shashi

?

On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com> wrote:

?

On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review and these questions help us to reach the right requirements.?

?

Without this change, there is different behavior on windows compared to Mac/Linux platforms. Hence this change is required to make the behavior same across the platforms. Since the scroll pane control is not displayed for the SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the user can move to a different position? Since we used to update/recalculate the scroll pane geometry caused changes to move to a different position other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the user is unable to control the scrolling movement because neither he can set one setScrollPosition() nor the control is displayed to explicitly set the movement. Hope this answers your question.

You need to think once again about two facts I brought in my previous message.

1. User still may scroll using mouse wheel even when scrollbars are not visible.

2. Visibility of scrollbars doesn't affect the requirement to notify the scroll about the scrolled component size changes. If the scrolled component was 500x500 in size and its position in the 200x200 viewport was (300,300) after the size of the component is changed to 300x300 it may not be shown at the same position because the previously visible component area doesn't exist anymore and the scroll should be moved to (100,100). This should work in the same way regardless the selected scrlollbar visibility policy.

--Semyon




?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Saturday, February 24, 2018 2:12 AM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?

?

Scroll pane geometry gets updated in 2 ways, one thro? setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don?t display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn?t made any difference.

The only difference of SCROLLBARS_NEVER from others I got from javadoc is that the scroll bar controls are hidden. So the scrolling itself happens in the same way as in the case of visible scroll bars but it can be only controlled by mouse wheel or programmatically. In my understanding this means that the notification about the scrolled component size changes should happen in the same way as for all other cases. I see no reason for the differentiation that your fix introduces. What will happen if to remove this notification for visible scroll bars modes?

--Semyon




?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Friday, February 23, 2018 10:17 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review comments.

?

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

?

This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case.

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Thursday, February 22, 2018 11:58 PM
To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

?

Bug:?https://bugs.openjdk.java.net/browse/JDK-8195738

?

Webrev:?HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

?

Problematic platform: Windows only.

?

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the?

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don?t need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

?

Thanks and regards,
Shashi

?

?

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180227/6d746987/attachment.html>

End of awt-dev Digest, Vol 130, Issue 41
****************************************

From shashidhara.veerabhadraiah at oracle.com  Tue Feb 27 15:51:55 2018
From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah)
Date: Tue, 27 Feb 2018 07:51:55 -0800 (PST)
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <b01398ea-f7c1-41a4-8845-20c0da99eccd@default>
References: <b01398ea-f7c1-41a4-8845-20c0da99eccd@default>
Message-ID: <eb824adb-920b-456e-bbed-a075a408ecd5@default>

Hi Krishna, Are you sure the test passes with mouseMoved() event callback(of Frame 2) being called? You need to see it via additional debugging only.

Threshold is added because I think it is quite possible especially with hidpi(fractional) since convert back and forth from user space to device coordinates which typically results in plus or minus 1 pixel correction(because of division or multiplication). The bug link contains the call stack where it is reported as (29, 29) as the location and hence the test fails.

Thanks and regards,
Shashi

-----Original Message-----
From: Krishna Addepalli 
Sent: Tuesday, February 27, 2018 7:50 PM
To: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails


Hi Shashi,

This test passes for me without any problems on my machine. I'm using Windows 10 build 1703 - i.e it is not Fall Creators build.

Also, the intent of the test is to check that, if a frame is drawn on top of another frame, then the mouse move should be seen by the top frame and not the bottom frame. Since we use Robot.mouseMove, I guess it should move to the exact location that we specify.
Frame2 is created at position (120,120). The mouse is moved to (149, 149) first and then to (150,150). So, effectively, mouse position should be (30,30) wrt second frame. I don't see a reason for adding some sort of threshold here like your fix suggests.
And also, since Frame2 is on top, frame2 should see the MouseMove, whereas Frame1 shouldnot see it.

There was a test bug JDK- 8027154, where a fix was done.

Thanks,
Krishna

Message: 1
Date: Mon, 26 Feb 2018 20:45:31 -0800 (PST)
From: Shashidhara Veerabhadraiah
	<shashidhara.veerabhadraiah at oracle.com>
To: Philip Race <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017:
	java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
	fails
Message-ID: <1a170b63-391b-416d-9cc2-4e66e2a63a76 at default>
Content-Type: text/plain; charset=us-ascii

Am using Windows 10 Pro    Version: 1703!! Do you suspect this has those specific mouse move issues?

Thanks and regards,
Shashi

-----Original Message-----
From: Philip Race
Sent: Tuesday, February 27, 2018 10:12 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails

What Windows 10 version are you running ? As discussed a few times ... 
probably off-list ..
there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.

-phil.

On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>
> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>
> Thanks and regards,
> Shashi
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Tuesday, February 27, 2018 4:05 AM
> To: Shashidhara Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>;
> awt-dev at openjdk.java.net
> Subject: Re:<AWT Dev>  [11] JDK-8196017: 
> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
> fails
>
> Hi, Shashi.
> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>
> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review a test fix for the below bug:
>>
>>           Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>
>>           Webrev:
>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>
>> Summary: The original bug
>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
>> for MacOS platform but the test is enabled to run on all platforms.
>> This is modified. Along with it exact positional comparison was done 
>> in the test and now modified to allow for leniency of around 2 pixels.
>>
>> Thanks and regards,
>> Shashi
>>
>
> --
> Best regards, Sergey.


------------------------------

Message: 2
Date: Mon, 26 Feb 2018 21:20:49 -0800 (PST)
From: Prem Balakrishnan <prem.balakrishnan at oracle.com>
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>,
	awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression
	automated Test
	'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java'
	fails
Message-ID: <1d8a8bcb-f771-44c1-9c41-a7fcd74f2efd at default>
Content-Type: text/plain; charset=us-ascii

Hi Sergey,

At times backFrame is rendered on top of frontFrame, due to which mouse position on backFrame is not NULL and test fails, solved this by adding waitForIdle() calls appropriately. Furthermore, mousemove from frontFrame to backFrame, caused the cursor to change to resize cursor and test fails, solved this by setting setResizable() to false. 

Regards,
Prem

-----Original Message-----
From: Sergey Bylokhov
Sent: Tuesday, February 27, 2018 3:59 AM
To: Prem Balakrishnan <prem.balakrishnan at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] Review Request: JDK-8196435 Regression automated Test 'java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java' fails

Hi, Prem.
> Test fails due to synchronization issue.

Can you please clarify what synchronization issue was fixed? The code before/after mostly identical except xxx.setResizable(false);


--
Best regards, Sergey.


------------------------------

Message: 3
Date: Mon, 26 Feb 2018 21:45:18 -0800
From: Phil Race <philip.race at oracle.com>
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8196017:
	java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
	fails
Message-ID: <B9523A46-3CFE-455F-A802-0F174C4ADB13 at oracle.com>
Content-Type: text/plain;	charset=us-ascii

Could be that it acquired the same bug via a patch release.

-Phil.

> On Feb 26, 2018, at 8:45 PM, Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com> wrote:
> 
> Am using Windows 10 Pro    Version: 1703!! Do you suspect this has those specific mouse move issues?
> 
> Thanks and regards,
> Shashi
> 
> -----Original Message-----
> From: Philip Race
> Sent: Tuesday, February 27, 2018 10:12 AM
> To: Shashidhara Veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> Cc: Sergey Bylokhov <sergey.bylokhov at oracle.com>; 
> awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11] JDK-8196017: 
> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java 
> fails
> 
> What Windows 10 version are you running ? As discussed a few times ... 
> probably off-list ..
> there is a bug in Windows 10 Fall Creators (build 1709) that breaks mouse moves.
> 
> -phil.
> 
>> On 2/26/18, 8:11 PM, Shashidhara Veerabhadraiah wrote:
>> Hi Sergey, Before I sent out this review I ran this test different platforms and saw that it was passing. But then after I sent it out for review I found that the test had not run on Windows 10!! That was strange and was not expecting it in the first place. I found that mouseMoved() event was never received for the frame 2!! And our test passes or fails within the frame 2's mouseMoved() event callback.
>> 
>> We do receive this event on mac and win 7 and am not sure why are we missing it on win 10. So I think it is good to make this test specific to mac as the original fix was specific to mac only and log a new bug to debug on this problem. I do not see as an issue with test as it is a simple test and it falsely passes even with normal dpi and hidpi on win 10. And bug JDK-8027154 was a test only update.
>> 
>> Thanks and regards,
>> Shashi
>> 
>> -----Original Message-----
>> From: Sergey Bylokhov
>> Sent: Tuesday, February 27, 2018 4:05 AM
>> To: Shashidhara 
>> Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>;
>> awt-dev at openjdk.java.net
>> Subject: Re:<AWT Dev>  [11] JDK-8196017: 
>> java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
>> fails
>> 
>> Hi, Shashi.
>> Why this test should be platform specific? It shows two common frames and use some generic api for mouse events.
>> This test also was updated in JDK-8027154 and I assume it should works on macOS after that, maybe we have a new regression here?
>> 
>>> On 24/02/2018 07:32, Shashidhara Veerabhadraiah wrote:
>>> Hi All, Please review a test fix for the below bug:
>>> 
>>>          Bug: https://bugs.openjdk.java.net/browse/JDK-8196017
>>> 
>>>          Webrev:
>>> http://cr.openjdk.java.net/~sveerabhadra/8196017/webrev.00/
>>> 
>>> Summary: The original bug
>>> https://bugs.openjdk.java.net/browse/JDK-8012026 fixed the code only 
>>> for MacOS platform but the test is enabled to run on all platforms.
>>> This is modified. Along with it exact positional comparison was done 
>>> in the test and now modified to allow for leniency of around 2 pixels.
>>> 
>>> Thanks and regards,
>>> Shashi
>>> 
>> 
>> --
>> Best regards, Sergey.



------------------------------

Message: 4
Date: Tue, 27 Feb 2018 00:45:26 -0800 (PST)
From: Shashidhara Veerabhadraiah
	<shashidhara.veerabhadraiah at oracle.com>
To: Semyon Sadetsky <semyon.sadetsky at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane
	is reset after calling validate()
Message-ID: <f88ed3d5-92fd-4a09-81d2-5b1f768b4459 at default>
Content-Type: text/plain; charset="utf-8"

Hi Semyon, Thanks for your help. I did some debugging from that perspective and could find the problem and the solution. Here is the new webrev, please review it:

?

http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/

?

The problem was that in the case of SCROLLBARS_NEVER, scroll bar info was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). This forced the windows to pick a default value and hence reset it to that value every time. Now the logic is modified in a very similar fashion as the other scroll bar display modes but without displaying it using the new win api ShowScrollBar(). The scroll bar info is supplied with a proper range per the corresponding base component but without the scroll bar pane size(as we don?t display it). This should suffice a good range for the scroll bars to operate and correct itself if there is any out of range value is supplied.

?

Thanks and regards,
Shashi

?

From: Semyon Sadetsky
Sent: Tuesday, February 27, 2018 1:22 AM
To: shashidhara veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
Cc: awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

The bug was failed against Windows platform. So, I'd try to find the root cause why when the scroll is notified with the scrolled component size the scroll position is set to the wrong value.

--Semyon

?

On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:

I think I agree Semyon. Thanks for your detailed explanation. 

?

So how do we approach on this? I see a different behaviour on other platforms. Shouldn?t we have a common behaviour across platforms? I agree with your analysis and hence should we change the behaviour on other platforms so that all of them will have the same behaviour?

?

Thanks and regards,

Shashi

?

On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky <HYPERLINK "mailto:semyon.sadetsky at oracle.com"semyon.sadetsky at oracle.com> wrote:

?

On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review and these questions help us to reach the right requirements.?

?

Without this change, there is different behavior on windows compared to Mac/Linux platforms. Hence this change is required to make the behavior same across the platforms. Since the scroll pane control is not displayed for the SCROLLBARS_NEVER case and if not in the setScrollPosition() then how can the user can move to a different position? Since we used to update/recalculate the scroll pane geometry caused changes to move to a different position other than the setScrollPosition()!! This causes SCROLLBARS_NEVER mode as unusable as the user is unable to control the scrolling movement because neither he can set one setScrollPosition() nor the control is displayed to explicitly set the movement. Hope this answers your question.

You need to think once again about two facts I brought in my previous message.

1. User still may scroll using mouse wheel even when scrollbars are not visible.

2. Visibility of scrollbars doesn't affect the requirement to notify the scroll about the scrolled component size changes. If the scrolled component was 500x500 in size and its position in the 200x200 viewport was (300,300) after the size of the component is changed to 300x300 it may not be shown at the same position because the previously visible component area doesn't exist anymore and the scroll should be moved to (100,100). This should work in the same way regardless the selected scrlollbar visibility policy.

--Semyon




?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Saturday, February 24, 2018 2:12 AM To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Whenever the container is resized we used to update the scroll pane sizes/geometry regardless of the scroll bar display policies. This resizing make sense for the non SCROLLBARS_NEVER cases as the scroll pane is displayed or needed an update. This additional update posed issues for the SCROLLBARS_NEVER case where we are not supposed to display the scroll pane per the java doc, then why update?

?

Scroll pane geometry gets updated in 2 ways, one thro? setScrollPosition() and childResized(). So I derived the conclusion based on the javadoc information that since we don?t display the scroll pane there is no need to update the scroll pane geometry based on the childResized() as it was altering the position already set by the setScrollPosition(). This behavior is same as the other non SCROLLBARS_NEVER mode and setting the scroll bar display to SCROLLBARS_NEVER didn?t made any difference.

The only difference of SCROLLBARS_NEVER from others I got from javadoc is that the scroll bar controls are hidden. So the scrolling itself happens in the same way as in the case of visible scroll bars but it can be only controlled by mouse wheel or programmatically. In my understanding this means that the notification about the scrolled component size changes should happen in the same way as for all other cases. I see no reason for the differentiation that your fix introduces. What will happen if to remove this notification for visible scroll bars modes?

--Semyon




?

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Friday, February 23, 2018 10:17 PM To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:

Hi Semyon, Thanks for your review comments.

?

Here are those different scroll bar pane modes and their description:

Modifier and Type

Field

Description

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS"SCROLLBARS_ALWAYS

Specifies that horizontal/vertical scrollbars should always be shown regardless of the respective sizes of the scrollpane and child.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED"SCROLLBARS_AS_NEEDED

Specifies that horizontal/vertical scrollbar should be shown only when the size of the child exceeds the size of the scrollpane in the horizontal/vertical dimension.

static int

HYPERLINK "https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER"SCROLLBARS_NEVER

Specifies that horizontal/vertical scrollbars should never be shown regardless of the respective sizes of the scrollpane and child.

?

This javadoc, you've copy-pasted here, doesn't explain why in your fix the notification about changed child size is disabled for SCROLLBARS_NEVER case.

Thanks and regards,
Shashi

?

From:?Semyon Sadetsky?
Sent:?Thursday, February 22, 2018 11:58 PM To:?Shashidhara Veerabhadraiah?HYPERLINK "mailto:shashidhara.veerabhadraiah at oracle.com"<shashidhara.veerabhadraiah at oracle.com>;?HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
Subject:?Re: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is reset after calling validate()

?

Hi Shashi,

Can you clarify what is the principal difference between SCROLLBARS_NEVER and other scroll policies that requires to avoid updating the scroll geometry according to the inner component size?

--Semyon

On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah wrote:

Hi All, Please review a code fix for the below bug.

?

Bug:?https://bugs.openjdk.java.net/browse/JDK-8195738

?

Webrev:?HYPERLINK "http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/"http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/

?

Problematic platform: Windows only.

?

Summary: This bug occurs only on windows platform and whereas the behavior is different on Mac/Linux platforms. Now after this fix there is common behavior across the platforms.

The main problem was with resetting the state of the scroll bars even though the scroll bar panes are spawned with SCROLLBARS_NEVER as the scroll bar display policy. This resetting should not occur as the scroll bar display policy makes the?

scroll bar panes invisible. Hence except the setScrollPosition() calls, we don?t need to resize/update the scroll bars state upon calling the scroll bars validation if SCROLLBARS_NEVER policy is used as the scroll bars are not displayed.

?

Thanks and regards,
Shashi

?

?

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180227/6d746987/attachment.html>

End of awt-dev Digest, Vol 130, Issue 41
****************************************

From krishna.addepalli at oracle.com  Tue Feb 27 17:56:25 2018
From: krishna.addepalli at oracle.com (Krishna Addepalli)
Date: Tue, 27 Feb 2018 09:56:25 -0800 (PST)
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <5A94A6C9.6060109@oracle.com>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>
 <5A94A6C9.6060109@oracle.com>
Message-ID: <5d39d881-12a1-44f5-b171-582eda9b60c0@default>

Hi Sergey/Phil,

Thanks for pointing that out. I have created a new webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev01/
 with the appropriate changes for ProblemList.txt as well.

I have tested on Windows 7, Ubuntu 16.04, Ubuntu 17.10 and MacOS 10.13, and the test passed with/without my changes.
As noted earlier, on Windows 10, the test passes after the fix.

Thanks,
Krishna

-----Original Message-----
From: Philip Race 
Sent: Tuesday, February 27, 2018 6:01 AM
To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
Cc: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev> [11][JDK-8197808] Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows

Yes .. even if bugs were added to the problem list in bulk, the expectation is that they'll be removed by the bug fix that fixes the failure.
And if it still fails on some platforms then either (1) you aren't done with your fix, or (2) you need to find a different bug ID under which to now exclude the test for the platform(s) that still fail for what would normally be some completely un-related reason.

Other than that the fix is fine.

-phil.

On 2/26/18, 2:16 PM, Sergey Bylokhov wrote:
> Hi, Krishna.
> This test was added to the problemlist, please check that it works on 
> other platforms and remove it from the problemlist.
>
> On 25/02/2018 17:53, Krishna Addepalli wrote:
>> Hi All,
>>
>> Please review a fix for JDK-8197808: 
>> https://bugs.openjdk.java.net/browse/JDK-8197808
>>
>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/
>>
>> The problem was that by the time Robot tries to read the color on 
>> screen, the compositing of the window is not completed, and hence, 
>> instead of reading Blue color, it is reading a combination of Blue 
>> and Red colors. Increasing the delay by 100 ms made sure that the 
>> composition is complete and the color is being read correctly. Also, 
>> this happens only on Windows 10.
>>
>> Apart from this, the test was not cleaning up the windows when it 
>> throws exception, so fixed that, and also added all explicit imports.
>>
>> Thanks,
>>
>> Krishna
>>
>
>

From semyon.sadetsky at oracle.com  Wed Feb 28 17:00:20 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Feb 2018 09:00:20 -0800
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <5d39d881-12a1-44f5-b171-582eda9b60c0@default>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>
 <5A94A6C9.6060109@oracle.com> <5d39d881-12a1-44f5-b171-582eda9b60c0@default>
Message-ID: <e6782210-ba06-5232-6fbe-3d27891e25d7@oracle.com>

Hi Krishna,

Does the line

EventQueue.invokeAndWait(() -> { /* Empty */ });

is really necessary for test to pass?

--Semyon


On 02/27/2018 09:56 AM, Krishna Addepalli wrote:
> Hi Sergey/Phil,
>
> Thanks for pointing that out. I have created a new webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev01/
>   with the appropriate changes for ProblemList.txt as well.
>
> I have tested on Windows 7, Ubuntu 16.04, Ubuntu 17.10 and MacOS 10.13, and the test passed with/without my changes.
> As noted earlier, on Windows 10, the test passes after the fix.
>
> Thanks,
> Krishna
>
> -----Original Message-----
> From: Philip Race
> Sent: Tuesday, February 27, 2018 6:01 AM
> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
> Cc: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
> Subject: Re: <AWT Dev> [11][JDK-8197808] Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows
>
> Yes .. even if bugs were added to the problem list in bulk, the expectation is that they'll be removed by the bug fix that fixes the failure.
> And if it still fails on some platforms then either (1) you aren't done with your fix, or (2) you need to find a different bug ID under which to now exclude the test for the platform(s) that still fail for what would normally be some completely un-related reason.
>
> Other than that the fix is fine.
>
> -phil.
>
> On 2/26/18, 2:16 PM, Sergey Bylokhov wrote:
>> Hi, Krishna.
>> This test was added to the problemlist, please check that it works on
>> other platforms and remove it from the problemlist.
>>
>> On 25/02/2018 17:53, Krishna Addepalli wrote:
>>> Hi All,
>>>
>>> Please review a fix for JDK-8197808:
>>> https://bugs.openjdk.java.net/browse/JDK-8197808
>>>
>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/
>>>
>>> The problem was that by the time Robot tries to read the color on
>>> screen, the compositing of the window is not completed, and hence,
>>> instead of reading Blue color, it is reading a combination of Blue
>>> and Red colors. Increasing the delay by 100 ms made sure that the
>>> composition is complete and the color is being read correctly. Also,
>>> this happens only on Windows 10.
>>>
>>> Apart from this, the test was not cleaning up the windows when it
>>> throws exception, so fixed that, and also added all explicit imports.
>>>
>>> Thanks,
>>>
>>> Krishna
>>>
>>


From krishna.addepalli at oracle.com  Wed Feb 28 17:08:01 2018
From: krishna.addepalli at oracle.com (Krishna)
Date: Wed, 28 Feb 2018 22:38:01 +0530
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <e6782210-ba06-5232-6fbe-3d27891e25d7@oracle.com>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>
 <5A94A6C9.6060109@oracle.com> <5d39d881-12a1-44f5-b171-582eda9b60c0@default>
 <e6782210-ba06-5232-6fbe-3d27891e25d7@oracle.com>
Message-ID: <7A6A4DA4-1CDF-425D-A00C-8C9F1EE3E1F6@oracle.com>

Hi Semyon,

I don?t think it is needed, but since it was included in the test, I just refactored it to a lambda.

Thanks,
Krishna

> On 28-Feb-2018, at 10:30 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
> 
> Hi Krishna,
> 
> Does the line
> 
> EventQueue.invokeAndWait(() -> { /* Empty */ });
> 
> is really necessary for test to pass?
> 
> --Semyon
> 
> 
> On 02/27/2018 09:56 AM, Krishna Addepalli wrote:
>> Hi Sergey/Phil,
>> 
>> Thanks for pointing that out. I have created a new webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev01/
>>  with the appropriate changes for ProblemList.txt as well.
>> 
>> I have tested on Windows 7, Ubuntu 16.04, Ubuntu 17.10 and MacOS 10.13, and the test passed with/without my changes.
>> As noted earlier, on Windows 10, the test passes after the fix.
>> 
>> Thanks,
>> Krishna
>> 
>> -----Original Message-----
>> From: Philip Race
>> Sent: Tuesday, February 27, 2018 6:01 AM
>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
>> Cc: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
>> Subject: Re: <AWT Dev> [11][JDK-8197808] Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows
>> 
>> Yes .. even if bugs were added to the problem list in bulk, the expectation is that they'll be removed by the bug fix that fixes the failure.
>> And if it still fails on some platforms then either (1) you aren't done with your fix, or (2) you need to find a different bug ID under which to now exclude the test for the platform(s) that still fail for what would normally be some completely un-related reason.
>> 
>> Other than that the fix is fine.
>> 
>> -phil.
>> 
>> On 2/26/18, 2:16 PM, Sergey Bylokhov wrote:
>>> Hi, Krishna.
>>> This test was added to the problemlist, please check that it works on
>>> other platforms and remove it from the problemlist.
>>> 
>>> On 25/02/2018 17:53, Krishna Addepalli wrote:
>>>> Hi All,
>>>> 
>>>> Please review a fix for JDK-8197808:
>>>> https://bugs.openjdk.java.net/browse/JDK-8197808
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/
>>>> 
>>>> The problem was that by the time Robot tries to read the color on
>>>> screen, the compositing of the window is not completed, and hence,
>>>> instead of reading Blue color, it is reading a combination of Blue
>>>> and Red colors. Increasing the delay by 100 ms made sure that the
>>>> composition is complete and the color is being read correctly. Also,
>>>> this happens only on Windows 10.
>>>> 
>>>> Apart from this, the test was not cleaning up the windows when it
>>>> throws exception, so fixed that, and also added all explicit imports.
>>>> 
>>>> Thanks,
>>>> 
>>>> Krishna
>>>> 
>>> 
> 


From semyon.sadetsky at oracle.com  Wed Feb 28 17:12:30 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Feb 2018 09:12:30 -0800
Subject: <AWT Dev> [11][JDK-8197808] Test
 java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on
 Windows
In-Reply-To: <7A6A4DA4-1CDF-425D-A00C-8C9F1EE3E1F6@oracle.com>
References: <a54ef0d5-fb1e-48e2-8832-12dbd7f595de@default>
 <ed21f647-8d12-d57d-e849-791a03afcf4b@oracle.com>
 <5A94A6C9.6060109@oracle.com> <5d39d881-12a1-44f5-b171-582eda9b60c0@default>
 <e6782210-ba06-5232-6fbe-3d27891e25d7@oracle.com>
 <7A6A4DA4-1CDF-425D-A00C-8C9F1EE3E1F6@oracle.com>
Message-ID: <9ac1e133-4c9a-070b-9af1-a816193a811e@oracle.com>

Please remove it when push. Util.waitForIdle(r) does all that required.

+1

--Semyon


On 02/28/2018 09:08 AM, Krishna wrote:
> Hi Semyon,
>
> I don?t think it is needed, but since it was included in the test, I just refactored it to a lambda.
>
> Thanks,
> Krishna
>
>> On 28-Feb-2018, at 10:30 PM, Semyon Sadetsky <semyon.sadetsky at oracle.com> wrote:
>>
>> Hi Krishna,
>>
>> Does the line
>>
>> EventQueue.invokeAndWait(() -> { /* Empty */ });
>>
>> is really necessary for test to pass?
>>
>> --Semyon
>>
>>
>> On 02/27/2018 09:56 AM, Krishna Addepalli wrote:
>>> Hi Sergey/Phil,
>>>
>>> Thanks for pointing that out. I have created a new webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev01/
>>>   with the appropriate changes for ProblemList.txt as well.
>>>
>>> I have tested on Windows 7, Ubuntu 16.04, Ubuntu 17.10 and MacOS 10.13, and the test passed with/without my changes.
>>> As noted earlier, on Windows 10, the test passes after the fix.
>>>
>>> Thanks,
>>> Krishna
>>>
>>> -----Original Message-----
>>> From: Philip Race
>>> Sent: Tuesday, February 27, 2018 6:01 AM
>>> To: Sergey Bylokhov <sergey.bylokhov at oracle.com>
>>> Cc: Krishna Addepalli <krishna.addepalli at oracle.com>; awt-dev at openjdk.java.net
>>> Subject: Re: <AWT Dev> [11][JDK-8197808] Test java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java fails on Windows
>>>
>>> Yes .. even if bugs were added to the problem list in bulk, the expectation is that they'll be removed by the bug fix that fixes the failure.
>>> And if it still fails on some platforms then either (1) you aren't done with your fix, or (2) you need to find a different bug ID under which to now exclude the test for the platform(s) that still fail for what would normally be some completely un-related reason.
>>>
>>> Other than that the fix is fine.
>>>
>>> -phil.
>>>
>>> On 2/26/18, 2:16 PM, Sergey Bylokhov wrote:
>>>> Hi, Krishna.
>>>> This test was added to the problemlist, please check that it works on
>>>> other platforms and remove it from the problemlist.
>>>>
>>>> On 25/02/2018 17:53, Krishna Addepalli wrote:
>>>>> Hi All,
>>>>>
>>>>> Please review a fix for JDK-8197808:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8197808
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8197808/webrev00/
>>>>>
>>>>> The problem was that by the time Robot tries to read the color on
>>>>> screen, the compositing of the window is not completed, and hence,
>>>>> instead of reading Blue color, it is reading a combination of Blue
>>>>> and Red colors. Increasing the delay by 100 ms made sure that the
>>>>> composition is complete and the color is being read correctly. Also,
>>>>> this happens only on Windows 10.
>>>>>
>>>>> Apart from this, the test was not cleaning up the windows when it
>>>>> throws exception, so fixed that, and also added all explicit imports.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Krishna
>>>>>


From semyon.sadetsky at oracle.com  Wed Feb 28 19:08:31 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Feb 2018 11:08:31 -0800
Subject: <AWT Dev> [11] JDK-8195738: scroll poistion in ScrollPane is
 reset after calling validate()
In-Reply-To: <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
References: <6c7e55de-d601-430b-8a17-1c64da46fba3@default>
 <2e4ef47b-a3d8-e386-33e2-7517b610fc5b@oracle.com>
 <299c2e0e-79e0-4410-8c03-2f5ae56e9313@default>
 <831e46f0-c5ac-eddc-4ad2-ad4bd68af2ae@oracle.com>
 <9447653d-6931-48a7-95e6-c72edd2defaa@default>
 <40c84c2a-db56-5f47-3815-b400e16742c3@oracle.com>
 <94e04514-2c02-4a57-b0f1-063508022355@default>
 <dfbbe7e1-8484-5242-c19b-a4f5de959729@oracle.com>
 <9ADA126A-989D-4E10-9E45-98F94B910AE8@oracle.com>
 <4396fac6-4870-aad9-6e5f-c4b5e274c423@oracle.com>
 <f88ed3d5-92fd-4a09-81d2-5b1f768b4459@default>
Message-ID: <143b8e3a-fc31-d1d9-ebcc-a6df28d08a42@oracle.com>

Hi Sashi,

The parent with and height shouldn't be decreased by the size of the 
scrollbars in case of SCROLLBARS_NEVER.

--Semyon


On 2/27/2018 12:45 AM, Shashidhara Veerabhadraiah wrote:
>
> Hi Semyon, Thanks for your help. I did some debugging from that 
> perspective and could find the problem and the solution. Here is the 
> new webrev, please review it:
>
> http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.01/>
>
> The problem was that in the case of SCROLLBARS_NEVER, scroll bar info 
> was set using setScrollInfo() with SIF_RANGE with ranges being (0, 0). 
> This forced the windows to pick a default value and hence reset it to 
> that value every time. Now the logic is modified in a very similar 
> fashion as the other scroll bar display modes but without displaying 
> it using the new win api ShowScrollBar(). The scroll bar info is 
> supplied with a proper range per the corresponding base component but 
> without the scroll bar pane size(as we don?t display it). This should 
> suffice a good range for the scroll bars to operate and correct itself 
> if there is any out of range value is supplied.
>
> Thanks and regards,
> Shashi
>
> *From:*Semyon Sadetsky
> *Sent:* Tuesday, February 27, 2018 1:22 AM
> *To:* shashidhara veerabhadraiah <shashidhara.veerabhadraiah at oracle.com>
> *Cc:* awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev> [11] JDK-8195738: scroll poistion in 
> ScrollPane is reset after calling validate()
>
> The bug was failed against Windows platform. So, I'd try to find the 
> root cause why when the scroll is notified with the scrolled component 
> size the scroll position is set to the wrong value.
>
> --Semyon
>
> On 02/26/2018 09:51 AM, shashidhara veerabhadraiah wrote:
>
>     I think I agree Semyon. Thanks for your detailed explanation.
>
>     So how do we approach on this? I see a different behaviour on
>     other platforms. Shouldn?t we have a common behaviour across
>     platforms? I agree with your analysis and hence should we change
>     the behaviour on other platforms so that all of them will have the
>     same behaviour?
>
>     Thanks and regards,
>
>     Shashi
>
>         On 26-Feb-2018, at 10:17 PM, Semyon Sadetsky
>         <semyon.sadetsky at oracle.com
>         <mailto:semyon.sadetsky at oracle.com>> wrote:
>
>         On 02/24/2018 05:27 AM, Shashidhara Veerabhadraiah wrote:
>
>             Hi Semyon, Thanks for your review and these questions help
>             us to reach the right requirements.
>
>             Without this change, there is different behavior on
>             windows compared to Mac/Linux platforms. Hence this change
>             is required to make the behavior same across the
>             platforms. Since the scroll pane control is not displayed
>             for the SCROLLBARS_NEVER case and if not in the
>             setScrollPosition() then how can the user can move to a
>             different position? Since we used to update/recalculate
>             the scroll pane geometry caused changes to move to a
>             different position other than the setScrollPosition()!!
>             This causes SCROLLBARS_NEVER mode as unusable as the user
>             is unable to control the scrolling movement because
>             neither he can set one setScrollPosition() nor the control
>             is displayed to explicitly set the movement. Hope this
>             answers your question.
>
>         You need to think once again about two facts I brought in my
>         previous message.
>
>         1. User still may scroll using mouse wheel even when
>         scrollbars are not visible.
>
>         2. Visibility of scrollbars doesn't affect the requirement to
>         notify the scroll about the scrolled component size changes.
>         If the scrolled component was 500x500 in size and its position
>         in the 200x200 viewport was (300,300) after the size of the
>         component is changed to 300x300 it may not be shown at the
>         same position because the previously visible component area
>         doesn't exist anymore and the scroll should be moved to
>         (100,100). This should work in the same way regardless the
>         selected scrlollbar visibility policy.
>
>         --Semyon
>
>
>             Thanks and regards,
>             Shashi
>
>             *From:*Semyon Sadetsky
>             *Sent:*Saturday, February 24, 2018 2:12 AM
>             *To:*Shashidhara
>             Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>             <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>             <mailto:awt-dev at openjdk.java.net>
>             *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll poistion
>             in ScrollPane is reset after calling validate()
>
>             On 2/23/18 10:57 AM, Shashidhara Veerabhadraiah wrote:
>
>                 Hi Semyon, Whenever the container is resized we used
>                 to update the scroll pane sizes/geometry regardless of
>                 the scroll bar display policies. This resizing make
>                 sense for the non SCROLLBARS_NEVER cases as the scroll
>                 pane is displayed or needed an update. This additional
>                 update posed issues for the SCROLLBARS_NEVER case
>                 where we are not supposed to display the scroll pane
>                 per the java doc, then why update?
>
>                 Scroll pane geometry gets updated in 2 ways, one thro?
>                 setScrollPosition() and childResized(). So I derived
>                 the conclusion based on the javadoc information that
>                 since we don?t display the scroll pane there is no
>                 need to update the scroll pane geometry based on the
>                 childResized() as it was altering the position already
>                 set by the setScrollPosition(). This behavior is same
>                 as the other non SCROLLBARS_NEVER mode and setting the
>                 scroll bar display to SCROLLBARS_NEVER didn?t made any
>                 difference.
>
>             The only difference of SCROLLBARS_NEVER from others I got
>             from javadoc is that the scroll bar controls are hidden.
>             So the scrolling itself happens in the same way as in the
>             case of visible scroll bars but it can be only controlled
>             by mouse wheel or programmatically. In my understanding
>             this means that the notification about the scrolled
>             component size changes should happen in the same way as
>             for all other cases. I see no reason for the
>             differentiation that your fix introduces. What will happen
>             if to remove this notification for visible scroll bars modes?
>
>             --Semyon
>
>
>                 Thanks and regards,
>                 Shashi
>
>                 *From:*Semyon Sadetsky
>                 *Sent:*Friday, February 23, 2018 10:17 PM
>                 *To:*Shashidhara
>                 Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                 <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                 <mailto:awt-dev at openjdk.java.net>
>                 *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                 poistion in ScrollPane is reset after calling validate()
>
>                 On 2/22/18 8:23 PM, Shashidhara Veerabhadraiah wrote:
>
>                     Hi Semyon, Thanks for your review comments.
>
>                     Here are those different scroll bar pane modes and
>                     their description:
>
>                     *Modifier and Type*
>
>                     	
>
>                     *Field*
>
>                     	
>
>                     *Description*
>
>                     |static int|
>
>                     	
>
>                     *SCROLLBARS_ALWAYS
>                     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_ALWAYS>*
>
>                     	
>
>                     Specifies that horizontal/vertical scrollbars
>                     should always be shown regardless of the
>                     respective sizes of the scrollpane and child.
>
>                     |static int|
>
>                     	
>
>                     *SCROLLBARS_AS_NEEDED
>                     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_AS_NEEDED>*
>
>                     	
>
>                     Specifies that horizontal/vertical scrollbar
>                     should be shown only when the size of the child
>                     exceeds the size of the scrollpane in the
>                     horizontal/vertical dimension.
>
>                     |static int|
>
>                     	
>
>                     *SCROLLBARS_NEVER
>                     <https://docs.oracle.com/javase/9/docs/api/java/awt/ScrollPane.html#SCROLLBARS_NEVER>*
>
>                     	
>
>                     Specifies that horizontal/vertical scrollbars
>                     should never be shown regardless of the respective
>                     sizes of the scrollpane and child.
>
>                 This javadoc, you've copy-pasted here, doesn't explain
>                 why in your fix the notification about changed child
>                 size is disabled for SCROLLBARS_NEVER case.
>
>                     Thanks and regards,
>                     Shashi
>
>                     *From:*Semyon Sadetsky
>                     *Sent:*Thursday, February 22, 2018 11:58 PM
>                     *To:*Shashidhara
>                     Veerabhadraiah<shashidhara.veerabhadraiah at oracle.com>
>                     <mailto:shashidhara.veerabhadraiah at oracle.com>;awt-dev at openjdk.java.net
>                     <mailto:awt-dev at openjdk.java.net>
>                     *Subject:*Re: <AWT Dev> [11] JDK-8195738: scroll
>                     poistion in ScrollPane is reset after calling
>                     validate()
>
>                     Hi Shashi,
>
>                     Can you clarify what is the principal difference
>                     between SCROLLBARS_NEVER and other scroll policies
>                     that requires to avoid updating the scroll
>                     geometry according to the inner component size?
>
>                     --Semyon
>
>                     On 02/19/2018 11:08 PM, Shashidhara Veerabhadraiah
>                     wrote:
>
>                         Hi All, Please review a code fix for the below
>                         bug.
>
>                         Bug:https://bugs.openjdk.java.net/browse/JDK-8195738
>
>                         Webrev:http://cr.openjdk.java.net/~sveerabhadra/8195738/webrev.00/
>                         <http://cr.openjdk.java.net/%7Esveerabhadra/8195738/webrev.00/>
>
>                         Problematic platform: Windows only.
>
>                         Summary: This bug occurs only on windows
>                         platform and whereas the behavior is different
>                         on Mac/Linux platforms. Now after this fix
>                         there is common behavior across the platforms.
>
>                         The main problem was with resetting the state
>                         of the scroll bars even though the scroll bar
>                         panes are spawned with SCROLLBARS_NEVER as the
>                         scroll bar display policy. This resetting
>                         should not occur as the scroll bar display
>                         policy makes the
>
>                         scroll bar panes invisible. Hence except the
>                         setScrollPosition() calls, we don?t need to
>                         resize/update the scroll bars state upon
>                         calling the scroll bars validation if
>                         SCROLLBARS_NEVER policy is used as the scroll
>                         bars are not displayed.
>
>                         Thanks and regards,
>                         Shashi
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180228/b8eecd00/attachment-0001.html>

From magnus.ihse.bursie at oracle.com  Wed Feb 28 20:12:49 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 28 Feb 2018 21:12:49 +0100
Subject: <AWT Dev> RFR: JDK-8198844 Clean up GensrcX11Wrappers
Message-ID: <e656babe-e57c-a396-5b18-33ba3c9553c8@oracle.com>

My hunt on technical debt continues. This time my aim has been on the 
sorry mess known as GensrcX11Wrappers.

I've disentangled it into two functions, one simple gensrc part that is 
actually run during the build, and which involves just a simple java 
tool and some pre-calculated data files, and a separate step for 
updating those pre-calculated data files. This step is now run using 
"make update-x11wrappers". It involves compiling a native binary, and 
running it on the target platform, so just as before, this assumes that 
you are not cross-compiling.

I'm not sure what role the "verification" step we had before ever 
played. For all the years we've been "verifying" this, we've detected no 
differences. In fact, as far as I understand, what we *really* would 
need to verify against, is the X11 libraries on the runtime system, i.e. 
where the users executes the JRE. But then again, we can assume that 
this matches, just as anyone compiling with header files on one place 
can assume that they can use the libraries elsewhere. The only reason, 
as I see it, to keep the generation in the makefiles at all, is to 
document how the files were generated, and to be ready for the need to 
update the files if the list of datatypes in xlibtypes.txt changes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198844
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.01

/Magnus


From dmitry.markov at oracle.com  Wed Feb 28 20:13:25 2018
From: dmitry.markov at oracle.com (Dmitry Markov)
Date: Wed, 28 Feb 2018 20:13:25 +0000
Subject: <AWT Dev> [11] RFR 8187635: On Windows Swing changes keyboard
 layout on a window activation
In-Reply-To: <bfa6eef7-b426-2bf1-2194-1cd2bf50db00@oracle.com>
References: <07594A6B-81FC-4432-9468-6CAF2EACBF41@oracle.com>
 <bfa6eef7-b426-2bf1-2194-1cd2bf50db00@oracle.com>
Message-ID: <F1DC8A51-2B66-43E7-B72D-BA4CF60314E2@oracle.com>

Thank you, Sergey!

Looking for the second +1 from someone else.

Thanks in advance,
Dmitry

> On 26 Feb 2018, at 22:43, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
> 
> Looks fine.
> 
> On 26/02/2018 04:55, Dmitry Markov wrote:
>> Hello,
>> Could you review a fix for jdk11, please?
>>  bug: https://bugs.openjdk.java.net/browse/JDK-8187635
>>  webrev: http://cr.openjdk.java.net/~dmarkov/8187635/webrev.00/
>> Problem description:
>> On Windows platform if AWT/Swing app is inactive (does not have focus) and user changes keyboard layout, the app window will receive the message WM_INPUTLANGCHANGE upon activation. During message processing we do NOT set the following flag g_bUserHasChangedInputLang. So the keyboard layout is switched back by AWT toolkit via WM_AWT_ACTIVATEKEYBOARDLAYOUT event.
>> Fix:
>> It is necessary to set the flag g_bUserHasChangedInputLang during processing of WM_INPUTLANGCHANGE to block execution of activateKeyboardLayout() from AwtToolkit.WndProc().
>> Testing:
>> I ran related AWT/Swing regression tests and did not observe any new failures.
>> Thanks,
>> Dmitry
> 
> 
> -- 
> Best regards, Sergey.


From semyon.sadetsky at oracle.com  Wed Feb 28 20:20:50 2018
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 28 Feb 2018 12:20:50 -0800
Subject: <AWT Dev> [11] RFR 8187635: On Windows Swing changes keyboard
 layout on a window activation
In-Reply-To: <F1DC8A51-2B66-43E7-B72D-BA4CF60314E2@oracle.com>
References: <07594A6B-81FC-4432-9468-6CAF2EACBF41@oracle.com>
 <bfa6eef7-b426-2bf1-2194-1cd2bf50db00@oracle.com>
 <F1DC8A51-2B66-43E7-B72D-BA4CF60314E2@oracle.com>
Message-ID: <7eb1f725-aede-decd-5fd3-65226bc1c85b@oracle.com>

+1

--Semyon


On 02/28/2018 12:13 PM, Dmitry Markov wrote:
> Thank you, Sergey!
>
> Looking for the second +1 from someone else.
>
> Thanks in advance,
> Dmitry
>
>> On 26 Feb 2018, at 22:43, Sergey Bylokhov <sergey.bylokhov at oracle.com> wrote:
>>
>> Looks fine.
>>
>> On 26/02/2018 04:55, Dmitry Markov wrote:
>>> Hello,
>>> Could you review a fix for jdk11, please?
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8187635
>>>   webrev: http://cr.openjdk.java.net/~dmarkov/8187635/webrev.00/
>>> Problem description:
>>> On Windows platform if AWT/Swing app is inactive (does not have focus) and user changes keyboard layout, the app window will receive the message WM_INPUTLANGCHANGE upon activation. During message processing we do NOT set the following flag g_bUserHasChangedInputLang. So the keyboard layout is switched back by AWT toolkit via WM_AWT_ACTIVATEKEYBOARDLAYOUT event.
>>> Fix:
>>> It is necessary to set the flag g_bUserHasChangedInputLang during processing of WM_INPUTLANGCHANGE to block execution of activateKeyboardLayout() from AwtToolkit.WndProc().
>>> Testing:
>>> I ran related AWT/Swing regression tests and did not observe any new failures.
>>> Thanks,
>>> Dmitry
>>
>> -- 
>> Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Wed Feb 28 20:52:59 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 28 Feb 2018 12:52:59 -0800
Subject: <AWT Dev> [11] JDK-8196017:
 java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails
In-Reply-To: <eb824adb-920b-456e-bbed-a075a408ecd5@default>
References: <b01398ea-f7c1-41a4-8845-20c0da99eccd@default>
 <eb824adb-920b-456e-bbed-a075a408ecd5@default>
Message-ID: <d0bf586b-698e-21d6-c951-cbe53457a360@oracle.com>

On 27/02/2018 07:51, Shashidhara Veerabhadraiah wrote:
> Threshold is added because I think it is quite possible especially with hidpi(fractional) since convert back and forth from user space to device coordinates which typically results in plus or minus 1 pixel correction(because of division or multiplication). The bug link contains the call stack where it is reported as (29, 29) as the location and hence the test fails.

If we have an incorrect conversion to/from device space somewhere, then 
we should check the reason of this bug instead of adding some threshold 
to the test.



-- 
Best regards, Sergey.