On Wed, 18 Aug 2021 23:57:38 GMT, Phil Race <p...@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. This pull request has now been integrated. Changeset: ddcd851c Author: Phil Race <p...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/ddcd851c43aa97477c7e406490c0c7c7d71ac629 Stats: 110 lines in 2 files changed: 108 ins; 1 del; 1 mod 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used Reviewed-by: kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/5177
