<Swing Dev> <AWT Dev> [14] RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON

[Jayathirth D V]

Hi Sergey,

Thanks for the clarification.
If test behavior has to be that it should fail when CAPS_LOCK is on then there is no need to change individual test cases where we are verifying alphabets.

There are only 2 regression tests which try to change locking state of CAPS_LOCK:
java\awt\Toolkit\LockingKeyStateTest\LockingKeyStateTest.java
java\awt\Toolkit\Headless\HeadlessToolkit.java

In case of HeadlessToolkit.java we expect to not get access to LockingState of the key so there is no need to update the code here. In case of LockingKeyState, I have added finally block to make sure that we restore key state in all cases.

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

Internal CI system is also green.

Thanks,
Jay

-----Original Message-----
From: Sergey Bylokhov 
Sent: Tuesday, November 12, 2019 4:53 AM
To: Jayathirth Rao <jayathirth.d.v at oracle.com>; Phil Race <philip.race at oracle.com>
Cc: awt-dev at openjdk.java.net; swing-dev at openjdk.java.net
Subject: Re: <Swing Dev> <AWT Dev> [14] RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON

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 <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at 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.