On Thu, 10 Jul 2025 01:02:37 GMT, Alexander Zvegintsev <azveg...@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
