JDK-8272602 : [macOS] not all KEY_PRESSED events sent when control modifier is used
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    11.0.12,11.0.12-oracle,13.0.8,15.0.4,17,18 11.0.12,11.0.12-oracle,13.0.8,15.0.4,17,18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2021-08-17
  • Updated: 2022-05-30
  • Resolved: 2021-08-20
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 15 JDK 17 JDK 18
11.0.13-oracleFixed 13.0.9Fixed 15.0.5Fixed 17.0.1Fixed 18 b12Fixed
Related Reports
Duplicate :  
JDK-8276786 - Ctrl+Space shortcut key can no longer be mapped to a key stroke
Relates :  
JDK-8260616 - Removing remaining JNF dependencies in the java.desktop module
Description
This got broken somewhere between jdk16.0.2 and jdk17-ea+22.
Latest EA is broken as well.

Run the reproducer, in awt window press control+space key combo.

expected behaviour:
key pressed: KEY_PRESSED,keyCode=17,keyText=⌃,keyChar=Undefined keyChar,modifiers=⌃,extModifiers=⌃,keyLocation=KEY_LOCATION_LEFT,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x11
key pressed: KEY_PRESSED,keyCode=32,keyText=␣,keyChar=' ',modifiers=⌃,extModifiers=⌃,keyLocation=KEY_LOCATION_STANDARD,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x20
key typed: KEY_TYPED,keyCode=0,keyText=Unknown keyCode: 0x0,keyChar=' ',modifiers=⌃,extModifiers=⌃,keyLocation=KEY_LOCATION_UNKNOWN,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x20
key released: KEY_RELEASED,keyCode=32,keyText=␣,keyChar=' ',modifiers=⌃,extModifiers=⌃,keyLocation=KEY_LOCATION_STANDARD,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x20
key released: KEY_RELEASED,keyCode=17,keyText=⌃,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_LEFT,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x11

actual behaviour:

key pressed: KEY_PRESSED,keyCode=17,keyText=⌃,keyChar=Undefined keyChar,modifiers=⌃,extModifiers=⌃,keyLocation=KEY_LOCATION_LEFT,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x11
key released: KEY_RELEASED,keyCode=17,keyText=⌃,keyChar=Undefined keyChar,keyLocation=KEY_LOCATION_LEFT,rawCode=0,primaryLevelUnicode=0,scancode=0,extendedKeyCode=0x11


other release trains got broken between april and july updates of 2021
Comments
Fix Request (11u): similar to 17u. Applies cleanly, testing: tier1, tier2, netbeans autocompletion by control+space
20-08-2021
Fix Request (13u): similar to 17u. Applies cleanly, testing: tier1, tier2, netbeans autocompletion by control+space
20-08-2021
Fix Request (15u): similar to previous. Applies cleanly, testing: jdk:tier1, tier2, netbeans autocompletion by control+space
20-08-2021
Fix Request: This fix is for a regression in JDK 17. It does not seem to meet the 17 stopper criteria since it is a platform-specific (macOS) client-side bug (and FWIW the fix risk is limited to the same) and is already out there in 11.0.12 (July CPU) and has been in JDK 17 since b09 (early Feb 2021) and was only discovered in the last few days. However it should be fixed in the earliest feasible update releases. The fix is just to use a different way of converting a macOS native string to a Java string. A new test is provided but since the updated fn is used in multiple places in the macOS client code it was necessary to re-run as many client tests as possible on macOS. Meaning all the automated ones, and select manual testing. The fix for JDK 18 linked in this bug should apply cleanly to JDK 17u Review link : https://git.openjdk.java.net/jdk/pull/5177
20-08-2021
Changeset: ddcd851c Author: Phil Race <prr@openjdk.org> Date: 2021-08-20 00:08:42 +0000 URL: https://git.openjdk.java.net/jdk/commit/ddcd851c43aa97477c7e406490c0c7c7d71ac629
20-08-2021
I believe I see the problem. It is in String conversion. When Ctrl-Space is pressed the generated string is of length one with the character code 0 (zero) Unfortunately the conversion to a Java string is using NewStringUTF which sees just a byte sequence that with zeros and hence sees it as a zero length null terminated string. We need to use a different JNI String API to be able to specify the expected number of characters ie NewString
18-08-2021
please evaluate
18-08-2021
I was able to bisect the regression and found the cause, it's JDK-8260616
18-08-2021
This also breaks Netbeans AutoComplete.
17-08-2021