On Mon, 18 Sep 2023 20:22:21 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> The problem you're running into here isn't due to any bug in JavaFX. The way >> KeyCodes identify keys works well for defining accelerators but not for >> using a Robot to generate a specific printable character. As an extreme >> example, if you're using a Greek keyboard there will be a key that has >> KeyCode.Z assigned to it so you can use Shortcut+Z to invoke Undo. But that >> key will generate a Greek letter when pressed by a human or a Robot. >> >> You can probably assume that anyone running these tests is using a >> Latin/Roman keyboard that can generate the lower-case letters a-z so one >> approach is to just stick to those characters in the typing tests. The other >> is to try to identify the layout using a Robot. For example, send >> KeyCode.DIGIT1 and see if that generates a '1'. If not you're probably on a >> French layout. >> >> Punctation and symbols are hopeless, there's just too much variation in the >> keyboard layouts. >> >>> Not only we get key events for wrong characters, but also shortcut(A) >>> generates `character = q, text = , code = UNDEFINED, metaDown, >>> shortcutDown]` which closes the test app :-( >> >> Could you provide more details (platform, keyboard, keyboard layout, etc.)? >> On the Mac PR #425 cleaned all this up in jfx21. > > I am running this on macOS 13.5.1 with several keyboard layouts enabled. > > A test that does keyPress(KeyCode.A) followed by a keyRelease(KeyCode.A) > generates the following sequence of events: > > With the US layout: > > > KeyEvent [source = TextArea@7da926e[styleClass=text-input text-area], target > = TextArea@7da926e[styleClass=text-input text-area], eventType = KEY_PRESSED, > consumed = false, character = , text = a, code = A] > KeyEvent [source = TextArea@7da926e[styleClass=text-input text-area], target > = TextArea@7da926e[styleClass=text-input text-area], eventType = KEY_TYPED, > consumed = false, character = a, text = , code = UNDEFINED] > KeyEvent [source = TextArea@7da926e[styleClass=text-input text-area], target > = TextArea@7da926e[styleClass=text-input text-area], eventType = > KEY_RELEASED, consumed = false, character = , text = a, code = A] > > > With the French layout: > > > KeyEvent [source = TextArea@75ffb50a[styleClass=text-input text-area], target > = TextArea@75ffb50a[styleClass=text-input text-area], eventType = > KEY_PRESSED, consumed = false, character = , text = q, code = A] > KeyEvent [source = TextArea@75ffb50a[styleClass=text-input text-area], target > = TextArea@75ffb50a[styleClass=text-input text-area], eventType = KEY_TYPED, > consumed = false, character = q, text = , code = UNDEFINED] > KeyEvent [source = TextArea@75ffb50a[styleClass=text-input text-area], target > = TextArea@75ffb50a[styleClass=text-input text-area], eventType = > KEY_RELEASED, consumed = false, character = , text = q, code = A] > > > And with a cyrillic layout it generates whatever cyrillic letter is mapped to > the key. So, basically, KeyCode is more like a scan code, which means there > is no reliable way to test key bindings using Robot, unless we limit > ourselves (and the test) to the US layout. Or is there another way? > > <img width="612" alt="Screenshot 2023-09-18 at 13 19 51" > src="https://github.com/openjdk/jfx/assets/107069028/8bd8745c-8973-449f-bf17-0473f5c0e0b6";> This is the behavior we saw on the Mac before PR #425 was integrated. As of JavaFX 21 keyPress(KeyCode.A) should generate an 'a' and never a 'q' on all Latin layouts and all platforms (on a Cyrillic layout you'll still get a Cyrillic character). I can't reproduce this with the test app (tests/manual/events/KeyboardTest.java). Is there a test in this PR I should be trying? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1329266886
