<AWT Dev> <Swing Dev>  RFR JDK-8233696:[TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON
jayathirth.d.v at oracle.com
Wed Nov 20 08:54:18 UTC 2019
Thanks for your inputs.
Please find updated webrev for review:
Internal Test CI is green with latest change.
> 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.
> 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:
>> 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:
>> Internal CI system is also green.
>> -----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>  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.
>>>> 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...
More information about the awt-dev