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

[Philip Race]

It would at least be nice if tests could report : expected "a", got "A" 
.. as that will be a helpful
clue if we get more such failures.

-phil.

On 11/14/19 1:25 AM, Jayathirth D V wrote:
> 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.
>