<AWT Dev> RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used

[Phil Race]

On Thu, 19 Aug 2021 21:05:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 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.
>
> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 47:
> 
>> 45:        return NULL;
>> 46:     }
>> 47:     jstring jStr = (*env)->NewStringUTF(env, [str UTF8String]);
> 
> Probably we should cleanup all usage of [nsstring UTF8String] in the code at some point.

Depends on what the source data is.
FWIW in the macOS code in java.desktop there are just 5 others and none of them were touched/added/changed by the JNF work. They are all pre-existing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5177