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

[Jayathirth Rao]

Hi Phil,

Thanks for your inputs.
Please find updated webrev for review:
http://cr.openjdk.java.net/~jdv/8233696/webrev.03/ <http://cr.openjdk.java.net/~jdv/8233696/webrev.03/>

Internal Test CI is green with latest change.

Thanks,
Jay

> On 15-Nov-2019, at 7:15 AM, Philip Race <philip.race at oracle.com> wrote:
> 
> 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.
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20191120/265760d8/attachment.html>