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.r...@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....@oracle.com>; Phil Race >> <philip.r...@oracle.com> >> Cc: awt-dev@openjdk.java.net; swing-...@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.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. >>
