JDK-8233696 : [TESTBUG]Some jtreg tests fail when CAPS_LOCK is ON
  • Type: Bug
  • Component: client-libs
  • Affected Version: 8,11,14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-11-06
  • Updated: 2023-08-09
  • Resolved: 2019-11-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14
11.0.8-oracleFixed 13.0.4Fixed 14 b26Fixed
Related Reports
Duplicate :  
JDK-8208514 - [TEST_BUG] java/awt/Toolkit/LockingKeyStateTest: State of Caps Lock is not true
Relates :  
JDK-8279538 - java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplashTest.java fails with "Focus is lost!" on Linux
Description
There are many jtreg tests which use Robot.keyPress() for alphabets and then verify the string with static string in test cases.

These test cases assume CAPS_LOCK will be off and in cases where CAPS_LOCK is on they fail.
Comments
Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly.
04-06-2020
I'll sponsor the push for you, Richard.
13-03-2020
Fix request (11u) I would like to downport this for parity with 11.0.8-oracle. Applies clean except copyright years. Tests succeed on MS Windows and Linux. On MacOS test/jdk/javax/swing/JFileChooser/8041694/bug8041694.java failed with and without the patch.
12-03-2020
I think Richard forgot jdk11u-fix-request, adding the tag on his behalf.
12-03-2020
[~serb]Done.
19-02-2020
[~jdv] Jay can you please backport this test stability fix to jdk11?
19-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/5602e016309b User: psadhukhan Date: 2019-12-03 07:13:08 +0000
03-12-2019
URL: https://hg.openjdk.java.net/jdk/client/rev/5602e016309b User: jdv Date: 2019-11-22 06:06:08 +0000
22-11-2019
There are only 2 tests cases which change the state of CAPS_LOCK key: java\awt\Toolkit\LockingKeyStateTest\LockingKeyStateTest.java java\awt\Toolkit\Headless\HeadlessToolkit.java In LockingKeyStateTest we can add finally check to force reset key states if test fails in between. In HeadlessToolkit test we should not make changes because in headless state we should not be even able to getLockingKeyState. So we should keep as it is, if we actually dont get HeadlessException then root cause of that should be fixed. As of now this tests doesnt fail.
14-11-2019
I started analysis to find any test cases which are making changes to CAPS_LOCK state and then not restoring it. But there can be genuine cases where CAPS_LOCK is on by default. So we can check lockingState for CAPS_LOCK and set it explicitly to "false" in test cases where we are using robot.keyPress(). But it looks like all platforms doesnt support this get and setLockingLeyState() and in our internal CI test system it failed. So we can fix these test cases only by making our conditions flexible(Doing verification for both CAPS_LOCK on and off use cases)
07-11-2019
Change is out for review and it stabilizes the test behavior for Windows and it is verified. In case of other platforms it doesn't change test behavior.
07-11-2019
java/awt/SplashScreen/MultiResolutionSplash/unix/UnixMultiResolutionSplashTest.java fails by default in Ubuntu 18.04, but its better to have CAPS_LOCK state management here also so that in future we dont face CAPS_LOCK issue. Exception in thread "main" java.lang.RuntimeException: Image with wrong resolution is used for splash screen! at UnixMultiResolutionSplashTest.testSplash(UnixMultiResolutionSplashTest.java:110) at UnixMultiResolutionSplashTest.main(UnixMultiResolutionSplashTest.java:77) null ----------System.err:(14/899)---------- java.lang.RuntimeException: Test Failed at UnixMultiResolutionSplashTest.createChildProcess(UnixMultiResolutionSplashTest.java:90) at UnixMultiResolutionSplashTest.main(UnixMultiResolutionSplashTest.java:72) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:833) Other 3 tests fail with just CAPS_LOCK on in my local Windows 10 machine.
06-11-2019
Went through 430 matches for keyPress() across 165 files and ran test cases with CAPS_LOCK where we were pressing alphabet keys. Found 3 test cases which fail when CAPS_LOCK is enabled. java/awt/SplashScreen/MultiResolutionSplash/MultiResolutionSplash.java java/awt/Toolkit/RealSync/Test.java javax/swing/JFileChooser/8041694/bug8041694.java We should maintain proper CAPS_LOCK state in these test cases.
06-11-2019
I am going through all test cases where we use Robot.keyPress() with alphabets and check their behaviour when we have CAPS_LOCK on.
06-11-2019