RFR: 8314906: [testbug] Create behavior tests for text input controls [v5]

[Martin Fox]

On Mon, 18 Sep 2023 20:22:21 GMT, Andy Goryachev <angorya at 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 at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = a, code = A]
> KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = a, text = , code = UNDEFINED]
> KeyEvent [source = TextArea at 7da926e[styleClass=text-input text-area], target = TextArea at 7da926e[styleClass=text-input text-area], eventType = KEY_RELEASED, consumed = false, character = , text = a, code = A]
> 
> 
> With the French layout:
> 
> 
> KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_PRESSED, consumed = false, character = , text = q, code = A]
> KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 75ffb50a[styleClass=text-input text-area], eventType = KEY_TYPED, consumed = false, character = q, text = , code = UNDEFINED]
> KeyEvent [source = TextArea at 75ffb50a[styleClass=text-input text-area], target = TextArea at 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