JDK-4817479 : Robot is generating multiple key events against single keystroke on Redhat Linux
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.2,5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS:
    linux,linux_redhat_9.0,linux_suse_sles_8.2,solaris_2.6,solaris_8 linux,linux_redhat_9.0,linux_suse_sles_8.2,solaris_2.6,solaris_8
  • CPU: x86,sparc
  • Submitted: 2003-02-12
  • Updated: 2004-06-04
  • Resolved: 2004-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.
5.0 b35Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Tested_Java_Release   : 1.4.2 build-16
Tested_Java_Location :  /net/koori.sfbay/p/jdk01/jdk/1.4.2/beta/b16/binaries/linux-i586
Tested_Machine_Name   : sqe-jpi-05/dnm-dtf-016
Tested O/S           :  redhat 7.3/redhat 8.0

Problem Description:
 Combination of methods keyPress(KeyCode) and keyRelease(KeyCode) in java.awt.Robot are not working as desired on Redhat linux8.0. Somehow it's generating multiple key events against the single keystroke(key is pressed and released once). Same piece of code works fine on linux7.3 and all other windows and solaris platforms

Steps to Reproduce :
a)Single key
1) Try to run the attached Robot1.java file. In this file key "t" is tried to press and release just only once using robot.
2) if you see the the text on the TextField as "tt" instead of "t" then the bug is reproduced

b)key combinations
1) Try to run the attached Robot.java file. In this file cliboard is being set with text "*Testing Robot*" and the same text is tried to get pasted on the textfield using CNTRL-V key combination.
2) If Instead of "*Testing Robot*" you happened to see "*Testing Robot**Testing Robot**TestingRobot**TestingRobot*..............*TestingRobot**TestingRobot*vvvvvvvvvvvvvvv"  then the bug is reproduced 

The bug is also getting reflected to the Prorobot. File using Prorobot(ProrobotTest.java) instead of Robot has been attached  with the bug report. 
One of the workaround suggested i.e Increase the key repeat delay on the RedHat 8.0 machine works fine. One has to set the delay to maximum.
But the reducing the robot delay within the code is not changing the behavior at all. We are specifying delays at two places (RobotTest1.java and RobotTest.java), one before the keyPress and one between the keyPress and keyRelease. Below are the code snipets

Delay1	        robot.setAutoDelay(500);	
Delay2        	robot.setAutoDelay(500);
Delay1        	robot.setAutoDelay(1000);
Delay2        	robot.setAutoDelay(500);
Following behavior has been noticed while evaluating the bug:
1) If the Delay1 is there the Delay2 becomes irrelevant i.e. one can still notice the repetion of keys even the Delay2 is completely removed. 
2) If the Delay1 is removed then it's work fine even without touching the Delay2 at all.  
It's quite interesting that what Delay1 has to do with keyPress and KeyRelease combination which is called before these two events has been called. Also we can't get rid of Delay1 ,as in our test cases we have to make sure that the Cliboard has been set with the desired contents so that the same contents can later be pasted to desired location to proceed with testing. 
###@###.### 2003-03-03
###@###.### 2003-10-28
JDK: mantis, tiger 
Platforms: RH8, RH9, Mercury, SuSE8.2, SLES
Window Manager: Metacity

Failed testcases: 31 testcases:
4812771 (dup of 4817479, this bug.)
4814272 (dup of 4812771)
4814244 (dup of 4812771)
4814233 (dup of 4812771)
4814222 (dup of 4812771)
4812845 (dup of 4812771)
4812831 (dup of 4812771)
4812816 (dup of 4812771)
4812809 (dup of 4812771)

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b35 tiger-beta2 VERIFIED IN: tiger-beta2

SUGGESTED FIX ------- robot_proc.c ------- *** /tmp/sccs.qpaa0r Mon Jan 5 16:59:23 2004 --- robot_proc.c Thu Dec 11 18:56:39 2003 *************** *** 32,42 **** --- 32,45 ---- #include "wsutils.h" #include "multiVis.h" + #include <X11/XKBlib.h> + static int32_t pipeToParent = -1; static Display * robotDisplay = NULL; static pid_t parent; static void robot_writeParentResult(char *bytes, int32_t nBytesToWrite); static int32_t num_buttons = 3; /* default to 3 mouse buttons */ + static Boolean resetXkbRepeat = False; static XImage * getWindowImage(Display * display, Window window, int32_t x, int32_t y, *************** *** 197,202 **** --- 200,207 ---- XDeviceInfo* devices; XDeviceInfo* aDevice; XButtonInfo* bInfo; + Status xkbResult; + XkbDescPtr controls; robot_traceln("CHILD: robot_setup"); *************** *** 271,276 **** --- 276,304 ---- robot_traceln("CHILD: XQueryExtension(XInput) unavailable - assuming % d mouse buttons", num_buttons); } + /* 4817479: + * The XKB extension is enabled by default on Linux, but not on Solaris. + * In cases where XKB is enabled AND key-repeat is also enabled, we need t o + * ask XKB to disable key repeat so that Robot.keyPress() will not cause + * more than one character to be typed. + */ + xkbResult = XkbQueryExtension(robotDisplay, &major_opcode, &first_event, & first_error, &majorp, &minorp); + + robot_traceln("CHILD: XkbQueryExtension returns %x, opcode_rtrn = %d, even t_rtrn = %d, error_rtrn = %d, major_in_out = %d, minor_in_out = %d\n", + xkbResult, major_opcode, first_event, first_error, majorp, minorp); + + if (xkbResult) { + controls = XkbGetMap(robotDisplay, XkbControlsMask, XkbUseCoreKbd); + if (controls) { + xkbResult = XkbGetControls(robotDisplay, XkbRepeatKeysMask | XkbCo ntrolsEnabledMask, controls); + if (xkbResult == Success) { + resetXkbRepeat = (controls->ctrls->enabled_ctrls & XkbRepeatKe ysMask) ? True : False; + robot_traceln("CHILD: resetXkbRepeat = %x\n", resetXkbRepeat); + } + XkbFreeClientMap(controls, 0 /* ignored */, True); + } + } + Exit: result.code = RES_SETUP; result.isXTestAvailable = isXTestAvailable; *************** *** 328,337 **** --- 356,378 ---- static void robot_keyEvent(RCmdKey * cmd, Boolean isDown) { robot_traceln("CHILD: robot_keyEvent key = 0x%x, isDown = %d", cmd->keySym , isDown); + + /* 4817479: + * We need to disable/enable key repeat on each key event. Otherwise we + * would interfere with other apps on the system (key repeat would be + * disabled whenever a Java app w/ a Robot were running on the system). + */ + if (resetXkbRepeat) { + XkbChangeEnabledControls(robotDisplay, XkbUseCoreKbd, XkbRepeatKeysMas k, 0); + } XTestFakeKeyEvent(robotDisplay, XKeysymToKeycode(robotDisplay, cmd->keySym), isDown, CurrentTime); + + if (resetXkbRepeat) { + XkbChangeEnabledControls(robotDisplay, XkbUseCoreKbd, XkbRepeatKeysMas k, 1); + } XFlush(robotDisplay); }

WORK AROUND Increase the key repeat delay on the RedHat 8.0 machine and/or decrease the amount of delay used by Robot. ###@###.### 2003-02-19 Disabling the XKB extension also avoids this problem. Uncomment the following line in your XF86Config file: Option "XkbDisable" ###@###.### 2003-12-10 Key repeat can also be disabled using xset -r from a terminal. This doesn't require changing the X server config. Reenable with xset r ###@###.### 2004-06-04

PUBLIC COMMENTS Verified the lists of 31 testcases in the bug not fail in tiger b43 on SLES8, RH9, mercury, SuSE8.2. ###@###.### 2004-03-24

EVALUATION This bug is easily reproducible on RH8.0 using 1.4, 1.4.1, and 1.4.2b16 (though I had to add a delay() to the test so the JTextField was ready for input once keyPress() is called). ###@###.### 2003-02-12 The problem is that the keyboard repeat is kicking in just before the key is released, so the letter is being "typed" twice. I've confirmed this by reducing the Robot's auto delay (avoiding the problem) as well as increasing the delay (which causes yet more 't's to be typed). You'll either have to increase the key repeat delay on your RedHat 8.0 machine (or disable auto-repeat altogether), or decrease the amount of Robot delay used in the tests. It is interesting, though, that even with a long auto-delay (2000ms), this problem does not appear on Solaris 9, Windows 2000, or RedHat 7.2(!). So something is going on with RedHat 8.0, presumably with the X server. This should be fixed so we can maintain cross-platform behavior. On a semi-related note, it might be useful to be able to retreive the key repeat delay and rate from the native toolkit. ###@###.### 2003-02-12 I just noticed that 4153069 also involved key auto-repeat, but I don't think it's related. ###@###.### 2003-02-12 It just occurred to me that Linux has XKB enabled by default, but Solaris does not. XKB has options for auto-repeat behavior, so this might be one area to investigate about the configuration difference. http://ftp.xfree86.org/pub/XFree86/4.0.3/doc/PostScript/XKBlib.PS ###@###.### 2003-12-10 Good thinking. Disabling XKB on Linux also avoids this problem. I'll continue investigating to see how we can get things working with XKB enabled. ###@###.### 2003-12-10 The fix for this bug is to check if XKB is enabled, and ask XKB to disable key repeat when doing a Robot key event. ###@###.### 2004-01-05 Name: dmR10075 Date: 01/06/2004 Actually, we have been facing this problem for a long time since RH8.0 appeared. The problem is in setting of X server. It can be retrieved using "xset -q", look for auto-repeat option. I don't think we need to fix anything here. The increased delay for auto-repeat(which 200ms or even 150ms by default) should be increased on every testing platform we have. Note that XKB has nothing to do with it - we get the same problem on Solaris with Xvfb or Xnest since their default values are also too small. The problem is also in tests - they use very long delays between keyPress and keyRelease which is wrong. We have reported this problem to SQE and I remember they agreed to fix Tonga and other tests to reduce the delay(I think we agreed on 100ms). ###@###.### 2004-1-6 ======================================================================