Re: [14] RFR JDK-8233703:java/awt/Frame/FrameLocation.java fails on mac

[Sergey Bylokhov]

On 11/7/19 8:22 pm, Prasanta Sadhukhan wrote:

OK. I will also try with more iterations on 18.04. But, one thing is test is 
calling removeNotify,addNotify which are not supposed to be called directly 
from programs. Shouldn't we use allowable APIs maybe setVisible(false), 
setVisible(true)?

BTW, I tried with 100 iterations on local ubuntu18.04 and it passed and I think 
mach5 system is also 18.04, so not sure why it will fail there.


Probably your local system too fast or too slow compared to the mach5 system.



Regards
Prasanta




Regards
Prasanta
On 08-Nov-19 2:42 AM, Sergey Bylokhov wrote:

Hi, Prasanta.

I think that the test passed after the fix is because it does not have enough 
time to update
the location of the Frame by the native callback.

Before the fix we have this sequence of calls:
 1 Sets the bounds of the frame(this bounds are cached in the frame and 
returned by getX/getY)
 2 Make the frame visible
 3 Wait while the callback from the native change the location of the frame 
cached at step 1
 4 Check the coordinates
 5 Destroy/Recreate the peer
 6 goto step  3

After the fix:
 1 Sets the bounds of the frame(this bounds are cached in the frame and 
returned by getX/getY)
 2 Make the frame visible
 3 Check the coordinates cached at step 1
 4 Destroy/Recreate the peer
 5 goto step  3

So actually the new test did not check location of the frame but check the 
values cached in the Frame object.


On 11/6/19 3:57 am, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for an issue where it is seen the frame location is 
sometimes wrong in mac on mach5 headful nightly run.

It seems to be a timing issue as it shows 10 frames by calling 
frame.removeNotify(),frame.addNotify() repeatedly, which by the way are not 
supposed to be called by programs directly.

Proposed fix is to make not to make thread sleep every time 
removeNotify,addNotify is called so that there is no delay. I have ran mach5 
job (in JBS) for 3 consecutive runs on all 3 platforms and they pass.

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

webrev: http://cr.openjdk.java.net/~psadhukhan/8233703/webrev.0/

Regards
Prasanta









--
Best regards, Sergey.

Re: [14] RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON

[Sergey Bylokhov]

On 11/10/19 9:15 pm, Jayathirth Rao wrote:

Hi Sergey,

I tested with get and setLockingKeyState() and it is not supported in all 
platforms. I got UnsupportedOperationException in Linux and MacOS in our 
internal test CI system.


But on platforms where it is supported, we can use it.


Also there can be cases where user has set CAPS_LOCK on explicitly and in that 
case also test should pass or gracefully exit instead of throwing failure.


In this case they should fail, since expectation of the test will be different 
from the actual behavior.


And these test cases are not explicitly expecting lower case alphabets, they 
are just taking input to check focus.
More analysis and how it behaves in internal test system is captured in JBS.


This is only because we found the root cause right now, there are might be 
other tests in the problem list that had the same root cause.

The right thing to do is to check all tests which press key modifiers such as 
capslock/shift/alt/meta and confirm that all of them release these keys on all 
code paths.



@Phil : Yes we should use equalsIgnoreCase() that would be more cleaner 
approach. I will update the webrev.

Thanks,
Jay


On 08-Nov-2019, at 2:27 AM, Sergey Bylokhov mailto:sergey.bylok...@oracle.com>> wrote:

On 11/7/19 4:23 am, Jayathirth D V wrote:

Solution : I tried many things like finding test cases where we might not be 
restoring the CAPS_LOCK state or using get/setLockingKeyState(). But they were 
not feasible solutions


Why this solution does not work?


so I am modifying the test cases which are failing because of CAPS_LOCK state 
to have proper checks. More details are in the bug.


I am not sure that this is the right thing to do if the test enters some text in
the text field and expects the low case text, then the text field should not 
return uppercase.

Otherwise you need to check other combinations when the shift/cmd/ctrl were 
pressed by other test.

--
Best regards, Sergey.





--
Best regards, Sergey.

[8u] RFR: 8221246: NullPointerException within Win32ShellFolder2

[Alex Kashchenko]

Hi,

Please review the backport of JDK-8221246 to 8u:

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

Original review thread: 
https://mail.openjdk.java.net/pipermail/awt-dev/2019-June/015273.html


11u changeset: 
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2f95ca679634


8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8221246/webrev.00/

Patch does not apply cleanly because of the differences in import 
section, all other code changes, besides imports, are left the same.


--
-Alex

Re: RFC: JDK-8231991: Mouse wheel change focus on awt/swing windows

[Dmitry Markov]

Hi Mario,

The fix looks good to me.

Thanks,
Dmitry

> On 11 Nov 2019, at 09:42, Mario Torre  wrote:
> 
> On Thu, 2019-10-31 at 12:00 +0100, Mario Torre wrote:
>> On Wed, 2019-10-30 at 15:45 -0700, Sergey Bylokhov wrote:
>>> Looks fine.
>> 
>> Thanks!
>> 
>> I believe I still need a second reviewer's approval? (or, is this
>> rule still in place?)
>> 
> 
> Ping?
> 
> Cheers,
> Mario
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH 
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 

Re: RFC: JDK-8231991: Mouse wheel change focus on awt/swing windows

[Mario Torre]

On Thu, 2019-10-31 at 12:00 +0100, Mario Torre wrote:
> On Wed, 2019-10-30 at 15:45 -0700, Sergey Bylokhov wrote:
> > Looks fine.
> 
> Thanks!
> 
> I believe I still need a second reviewer's approval? (or, is this
> rule still in place?)
> 

Ping?

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Re: [14] RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON

[Jayathirth D V]

Hi,

 

Please find updated webrev with equalsIgnoreCase():

 

http://cr.openjdk.java.net/~jdv/8233696/webrev.01/

 

Thanks,

Jay

 

From: Jayathirth Rao 
Sent: Monday, November 11, 2019 10:45 AM
To: Sergey Bylokhov ; Phil Race 

Cc: awt-dev@openjdk.java.net; swing-...@openjdk.java.net
Subject: Re:   [14] RFR JDK-8233696:[TESTBUG]Some jtreg 
tests fail when CAPS_LOCK is ON

 

Hi Sergey,

 

I tested with get and setLockingKeyState() and it is not supported in all 
platforms. I got UnsupportedOperationException in Linux and MacOS in our 
internal test CI system.

Also there can be cases where user has set CAPS_LOCK on explicitly and in that 
case also test should pass or gracefully exit instead of throwing failure.

 

And these test cases are not explicitly expecting lower case alphabets, they 
are just taking input to check focus.

More analysis and how it behaves in internal test system is captured in JBS.

 

@Phil : Yes we should use equalsIgnoreCase() that would be more cleaner 
approach. I will update the webrev.

 

Thanks,

Jay





On 08-Nov-2019, at 2:27 AM, Sergey Bylokhov mailto:sergey.bylok...@oracle.com"sergey.bylok...@oracle.com> wrote:

 

On 11/7/19 4:23 am, Jayathirth D V wrote:



Solution : I tried many things like finding test cases where we might not be 
restoring the CAPS_LOCK state or using get/setLockingKeyState(). But they were 
not feasible solutions


Why this solution does not work?




so I am modifying the test cases which are failing because of CAPS_LOCK state 
to have proper checks. More details are in the bug.


I am not sure that this is the right thing to do if the test enters some text in
the text field and expects the low case text, then the text field should not 
return uppercase.

Otherwise you need to check other combinations when the shift/cmd/ctrl were 
pressed by other test.

-- 
Best regards, Sergey.