JDK-8087486 : [Glass, Linux, Mac, Monocle] KeyCharacterCombination matching for tab and newline is broken
  • Type: Bug
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: jfx11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-09-25
  • Updated: 2025-01-16
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 :  
Relates :  
Relates :  
Description
See RT-38778 for more details. Sample:

public class Hello {
    static class KeyPair {
        private String character;
        private KeyCode code;

        KeyPair(String character, KeyCode code) {
            this.character = character;
            this.code = code;
        }
    }

    public static void main(String[] args) {
        new JFXPanel(); // initialize JavaFX

        for (KeyPair kp : Arrays.asList(new KeyPair("\n", KeyCode.ENTER), new KeyPair("\t", KeyCode.TAB))) {
            KeyCharacterCombination kcc = new KeyCharacterCombination(kp.character);
            KeyEvent event = new KeyEvent(KeyEvent.KEY_PRESSED, kp.character, "", kp.code, false, false, false, false);
            System.out.println("KeyCode." + kp.code.getName() + " matches: " + kcc.match(event)); // true (!!!)
        }

        Platform.exit();
    }
}

Comments
I have two questions about the table itself and a few other comments: 1) Several of the ASCII chars in the table are shifted chars. For example, on a standard US keyboard, the '@' symbol is a keycode of '2' with the shift modifier set. Ditto for ':' being a shifted ';'. The Monocle implementation of the method (which will be short-circuited with your table) converts the shifted chars to their unshifted counterparts. Your table doesn't do this, which is a change in behavior. Can you comment on this? 2) Does this table work for non-English locales or non-English keyboards? Once the above two issues are addressed, I have a few minor questions / comments: 3) Most of the non-ASCII chars in the table are 0. I realize that VK_UNDEFINED == 0, and is defined in this same file, but this is not a best practice and can lead to confusion. Please add a comment before the table explaining this. 4) The indentation of the table is a little odd: I think it would look better lined up. 5) A blank line between the end of the table and the javadoc comment for the following method would be nice. 6) It will need a unit test, possibly as a follow-on JIRA. One thing that occurred to me today is that you might want to test the new method directly, rather than indirectly via the public API, so that you don't need to initialize the toolkit to run the test.
15-11-2014

Please review: http://cr.openjdk.java.net/~ddhill/RT-38797/ I did try to fix this with native code, but could not find a documented way of checking the keyboard on MacOSX. And on other platforms, the presence of the key tends to be done with a table that may not map to a real attached keyboard. So used a lookup table for the most likely common use cases for this call.
14-11-2014

Passes: windows Fails: Linux/GTK, Mac, ARM/Monocle
28-10-2014