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.bylok...@oracle.com
<mailto:sergey.bylok...@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.
