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

[Martin Fox]

On Mon, 18 Sep 2023 16:42:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I ran the TextAreaBehaviorRobotTest on macOS 13.5.2. Test passed with my keyboard set to U.S. English and failed when set to French.
>> 
>> 
>> TextAreaBehaviorRobotTest > testTyping() FAILED
>>     org.opentest4j.AssertionFailedError: in step 2 ==> expected: <0123456789.,abracadabra> but was: <à&é"'(§è!ç,abracadabra>
>
> Merci, Monsieur Fox!
> 
> We seem to have quite a few tickets in this area (who created the first one in the list?):
> 
> * [JDK-8278924](https://bugs.openjdk.org/browse/JDK-8278924) [Linux] Robot key test can fail if multiple keyboard layouts are installed
> * [JDK-8022079](https://bugs.openjdk.org/browse/JDK-8022079) [macosx] swing shortcuts are counterintuitive with non-english keyboard layouts
> * [JDK-8087915](https://bugs.openjdk.org/browse/JDK-8087915) Mac: accelerator doesn't take into account azerty keyboard layout
> * [JDK-4760902](https://bugs.openjdk.org/browse/JDK-4760902) java.awt.Robot can't generate % character on FRENCH keyboard
> 
> 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 :-(
> 
> I have no idea how to fix this test...  We could try to introduce a translation layer to emit the right sequences (for each keyboard layout), or, alternatively, we could skip the tests altogether for non-US keyboard, except ... there seems to be no easy way to determine the keyboard layout?  (There are some suggestions involving InputContext or JNI on stackoverflow).  We could also try to skip the test if Locale.getDefault is other than Locale.US, not sure if that would solve the issue.
> 
> What do you think?

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.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1221#discussion_r1329214340