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.
