RFR: 8360647: [XWayland] [OL10] NumPad keys are not triggered

[Harshitha Onkar]

On Thu, 10 Jul 2025 01:02:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> When we try to pass `XK_KP_0` to [`NotifyKeyboardKeysym`](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html#org-freedesktop-portal-remotedesktop-notifykeyboardkeysym) in Remote Desktop API, it presses/releases `SHIFT` + `XK_KP_Insert`.
>> 
>> To get the same result as XTest api when using `NotifyKeyboardKeysym` we should use `XK_KP_Insert` instead of `XK_KP_0` regardless of NumLock state. Similarly for other Numpad keys.
>
>> The test _expects_ to receive Insert (not 0) even if numlock is on ? Why is that ?
>> It isn't really mentioned but this about Robot, isn't it ? What happens if a user types directly ?
> 
> The test doesn't care which button is pressed. It stores the keyCode-keyChar pair in a map received from the keyPressed event.
> Later, it checks whether the keyChar in the subsequent keyReleased event for the same keyCode matches the keyChar in the keyPressed event for that keyCode. It just checks for consistency.
> 
> https://github.com/openjdk/jdk/blob/518536c607cb383e810ee0f50f8af44e121f4ab3/test/jdk/java/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java#L45-L55
> 
> Before the fix, it was receiving:
> * Numlock on: KEY_PRESSED with `keyChar=Undefined keyChar` and KEY_RELEASED with `keyChar='0'`  / NumPad-0 keyCode
> * Numlock off: Undefined keyChar was received in both cases; the test didn't fail.  / Insert keyCode
> 
> After the fix, everything is consistent, and the same key events are reported as if they were pressed by a user.
> 
>> Can you please put an evaluation in the bug report.
> 
> Sure.
> 
>> Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.
> 
> Yes, it is.

@azvegint This is in regards to the regression test for this fix. The existing test `/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java` does not correctly reproduce the issue when Numlock is not "ON" on the testing system.

To better replicate the problem without the fix, adding a new test for this fix is good.
- Test only the Numpad keys (0x60 to 0x6F)
- Automate the Numlock 'On' and reset it at the end of the test probably in the finally block


robot.keyPress(KeyEvent.VK_NUM_LOCK);
robot.keyRelease(KeyEvent.VK_NUM_LOCK);
for(int vkey = 0x60; vkey < 0x6F; vkey++) {
    try {
        robot.keyPress(vkey);
        robot.keyRelease(vkey);
        System.out.println(KeyEvent.getKeyText(vkey) + " " + vkey);
    } catch (RuntimeException e) {
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26170#issuecomment-3059527965