JDK-6280734 : java.awt.Robot incorrectly dispatch VK_DELETE on Solaris 10
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0u3
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2005-06-06
  • Updated: 2019-12-17
  • Resolved: 2019-12-17
Related Reports
Relates :  
JDK-4966137 - Robot presses Numpad del key instead of normal Del key
Relates :  
JDK-6977762 - F11 and F12 keys are not reported on Solaris
Description
Robot incorrectly dispatch VK_DELETE on Solaris 10 sparc. It prints VK_PERIOD (0x2E, ".") instead of VK_DELETE (0x7F). It blocks our UI tests of NetBeans IDE.
When you run attached jar, it should not print "." at the end but delete one char. The source code is as follows:

    System.out.print("Should not print \".\" but delete last char from 1234: 1234");
    Robot robot = new Robot();
    robot.keyPress(KeyEvent.VK_DELETE);
    robot.keyRelease(KeyEvent.VK_DELETE);
    System.out.println("");

###@###.### 2005-06-06 09:08:15 GMT
Comments
EVALUATION After many experiments, we have found only one hardware configuration with described behavior: Sparc with KVM switch reporting Type 4 keyboard to an OS (Solaris 10, incidentally). A reverse lookup of keysym by awt keycode in XWindow.c awt_getX11KeySym() returns, invariably, Delete with Standard location - there's simple linear search in an array - however when this newfound keysym is fed back to AWT, it looks like coming from NumPad. To pass this bug to Solaris team would require a similarly behaving native code snippet. I don't have such a KVM switch here; hacking this code in Russia and testing it (physically, on KVM) in Prague seems wasteful. Let's wait for serious business reason to escalate this bug. ###@###.### 2005-06-28 12:18:14 GMT
06-06-2005