JDK-8316307 : Robot does not send keypad navigation events
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: window-toolkit
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-09-14
  • Updated: 2024-10-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8341560 - Better documentation for KeyCombinations/KeyCodes/KeyEvents
Relates :  
JDK-8314906 - [testbug] Create behavior tests for text input controls
Description
Robot does not send the following key events, as tested on macOS 13.5.1 and Windows 11:

KP_DOWN
KP_LEFT,
KP_RIGHT,
KP_UP

To reproduce, run the attached program and notice no events being sent for KP_* key codes:

keycode=LEFT key.press=LEFT
keycode=KP_LEFT key.press=null
keycode=KP_RIGHT key.press=null
keycode=KP_DOWN key.press=null
keycode=KP_UP key.press=null
keycode=RIGHT key.press=RIGHT
keycode=DOWN key.press=DOWN
keycode=UP key.press=UP

(was found while writing behavior tests for JDK-8314906)
Comments
Maybe the best thing to do would be to deprecate the KP_{LEFT,RIGHT,UP,DOWN} constants, and remove any internal references to them, such as the input maps for those controls that currently define a binding for them.
16-09-2023
I can't see any way forward to implementing this enhancement. As I understand it the idea is to use a Robot to generate a KeyEvent that is encoded as, say, KP_LEFT. The platform API's don't allow us to generate a key event that ignores the Num Lock state. If the Robot sends KP_LEFT while Num Lock is engaged what you'll get back is NUMPAD4. If Num Lock is not engaged the key event will go through the long-standing Glass logic and be assigned KeyCode LEFT instead of KP_LEFT. There's no good way for us to know that the Robot generated the event and use different code assignment logic. And macOS doesn't even have the notion of directional keys on the numeric keypad. Note: the Num Lock issue also comes up if we use a Robot to generate, say, NUMPAD4. On Linux the resulting key event will be either NUMPAD4 or LEFT depending on the Num Lock state. Surprisingly Windows ignores the Num Lock state and we always get NUMPAD4 back (at least, it surprised me). I don't think this can be carried over to KP_LEFT; for NUMPAD4 we send the OS a virtual key code but for KP_LEFT we would have to use a scan-code which works at a lower level.
15-09-2023
Better still, let's change it to an Enhancement request.
15-09-2023
Thank you so much for the research. I think this issue can be safely downgraded to P5.
15-09-2023
I don't know why someone went through the trouble of adding the KP_ key bindings. I suppose if someone looks at the list of KeyCodes it's reasonable to assume that there are systems out there that actually send KP_LEFT and LEFT as separate codes but so far I haven't been able to find any. AWT does the same thing. It defines separate codes (VK_LEFT and VK_KP_LEFT) but at least on Windows both keys generate VK_LEFT. If JavaFX is embedded VK_LEFT is then mapped to KeyCode.LEFT. The Apple support documentation vaguely suggests that the numeric keypad might work for navigation in some apps but it's not an OS-level setting.
15-09-2023
Just tested IBM keyboard connected to my mac: the numeric pad arrow keys generate numbers, because NumLock key apparently does not work. There is nothing in the System Settings app that even mentions NumLock.
14-09-2023
Thank you [~mfox] for such an informative insight! I wonder what was the reason behind explicitly adding key bindings for keypad arrow keys in text controls (TextArea/TextField/PasswordField): https://github.com/openjdk/jfx/blob/f7b21e5468f1aad18df17443590c0887b2cf0239/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java#L276 Perhaps, at least on Mac, it is to handle an externally connected keyboard?
14-09-2023
As far as I know KP_LEFT, KP_RIGHT, etc. have never been implemented in desktop JavaFX. No key press event will ever have one of these KeyCodes assigned and a Robot will just ignore them. When Num Lock is off in Windows the direction keys on the numeric keypad are mapped to LEFT, RIGHT, HOME, etc. instead of KP_LEFT, KP_RIGHT, KP_HOME. The OS itself is doing this; it sends the same virtual key code for a keypad key as it does for the non-keypad equivalent. There's probably a way for glass to distinguish between the two but it never has. On Linux the OS may distinguish between these keys but the glass code does not. Glass deliberately maps the keyval for the left arrow key (Left) and the keyval for keypad left (KP_Left) to the same JavaFX code. Again, it looks like it's always done this. Macs have never dealt with these codes since they don't have Num Lock keys.
14-09-2023
I get the same behavior on Windows 10 and on Linux.
14-09-2023