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

[Andy Goryachev]

On Fri, 15 Sep 2023 23:02:12 GMT, Martin Fox <duke at openjdk.org> wrote:

>> Interesting.  
>> 
>> It is my understanding though that for the purposes of this test it should work as expected.  I've added `TextAreaBehaviorRobotTest.testTyping()` - could you try running it with your setup please?
>> 
>> 
>>     @Test
>>     public void testTyping() throws Exception {
>>         execute(
>>             //addKeyListener(),
>>             "0123456789.,abracadabra",
>>             checkText("0123456789.,abracadabra", 23)
>>         );
>>     }
>
> 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?

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

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