<Swing Dev> <AWT Dev> [14] RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON
Sergey Bylokhov
Sergey.Bylokhov at oracle.com
Wed Nov 20 23:01:54 UTC 2019
+1
On 11/20/19 12:54 am, Jayathirth Rao wrote:
> Hi Phil,
>
> Thanks for your inputs.
> Please find updated webrev for review:
> 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 <mailto: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.
>>>
>
--
Best regards, Sergey.
More information about the swing-dev
mailing list