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. 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.
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. @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> > 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.
