When Ctrl+Space is pressed mac generates a string that contains the single unicode code point zero. The fn that converts it from an NSString to a Java String is using NewStringUTF. The input to that is a null terminated string which also has zero as the code point it contains, so we actually end up with a zero length Java string instead of the intended one code point in length. So the fix is to change the way we convert the string.
There's an existing test CtrlAscii.java which sort of tests some of this but it isn't asserting that you get what you expect, its mostly testing you don't get something *unexpected* .. it will happily pass if you don't get keyevents. I did not want to change the purpose of that test for this. So I wrote a test specific to this Ctrl+Space to verify the fix but also ran all the standard automated tests too. ------------- Commit messages: - 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used - 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used Changes: https://git.openjdk.java.net/jdk/pull/5177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272602 Stats: 110 lines in 2 files changed: 108 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5177/head:pull/5177 PR: https://git.openjdk.java.net/jdk/pull/5177
