[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-awt-dev
Subject:    Re: <AWT Dev> RFR: 8272602: [macos] not all KEY_PRESSED events sent when control modifier is used
From:       Phil Race <prr () openjdk ! java ! net>
Date:       2021-08-19 21:28:22
Message-ID: CksOY-pU_9MCQrCfQnm3ZfBh-amqalbXsFcp5TiW8Ik=.40ebfcad-2d7b-4a3c-bdbb-db952d03cf3a () github ! com
[Download RAW message or body]

On Thu, 19 Aug 2021 21:05:46 GMT, Sergey Bylokhov <serb@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


[prev in list] [next in list] [prev in thread] [next in thread]