Skip to content

8360647: [XWayland] [OL10] NumPad keys are not triggered #26170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

azvegint
Copy link
Member

@azvegint azvegint commented Jul 7, 2025

When we try to pass XK_KP_0 to 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.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8360647: [XWayland] [OL10] NumPad keys are not triggered (Bug - P3)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26170/head:pull/26170
$ git checkout pull/26170

Update a local copy of the PR:
$ git checkout pull/26170
$ git pull https://git.openjdk.org/jdk.git pull/26170/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26170

View PR using the GUI difftool:
$ git pr show -t 26170

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26170.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Jul 7, 2025

👋 Welcome back azvegint! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk
Copy link

openjdk bot commented Jul 7, 2025

@azvegint This change is no longer ready for integration - check the PR body for details.

@openjdk
Copy link

openjdk bot commented Jul 7, 2025

@azvegint The following label will be automatically applied to this pull request:

  • client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added client [email protected] rfr Pull request is ready for review labels Jul 7, 2025
@mlbridge
Copy link

mlbridge bot commented Jul 7, 2025

Webrevs

@mrserb
Copy link
Member

mrserb commented Jul 8, 2025

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.

Will Java receive the same keycodes if these events come from native code?

@azvegint
Copy link
Member Author

azvegint commented Jul 8, 2025

Will Java receive the same keycodes if these events come from native code?

Yes, java receives the same events for both remote desktop emulated keystrokes and physical keystrokes, whether NumLock is on or off.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Jul 9, 2025
@prrace
Copy link
Contributor

prrace commented Jul 9, 2025

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 ?

Can you please put an evaluation in the bug report.
Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.

@azvegint
Copy link
Member Author

azvegint commented Jul 10, 2025

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.

public void keyPressed(KeyEvent e){
transMap.put(e.getKeyCode(), e.getKeyChar());
}
public void keyReleased(KeyEvent e){
Object value = transMap.get(e.getKeyCode());
if (value != null && e.getKeyChar() != ((Character)value).charValue()) {
throw new RuntimeException("Wrong KeyChar on KEY_RELEASED "+
KeyEvent.getKeyText(e.getKeyCode()));
}
}

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.

@honkar-jdk
Copy link
Contributor

honkar-jdk commented Jul 10, 2025

@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 changeset might be a good idea.

  • Test only the Numpad keys (0x60 to 0x6F)
  • Automate Numlock set and reset (reset can be done 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) {
    }
}

@openjdk openjdk bot removed the ready Pull request is ready to be integrated label Jul 11, 2025
@azvegint
Copy link
Member Author

To better replicate the problem without the fix, adding a new test for this changeset might be a good idea.

I don't think a new test is necessary. I updated the existing one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client [email protected] rfr Pull request is ready for review
Development

Successfully merging this pull request may close these issues.

4 participants