Bugzilla – Bug 491282
pyatspi.Registry.generateKeyboardEvent incorrectly types keys that are typed using the shift key
Last modified: 2010-05-20 18:01:05 UTC
PROBLEM STATEMENT pyatspi provides a generateKeyboardEvent method that can be used to simulate the pressing of a key on the keyboard. The method's first parameter is the value of the key for which the event is generated. Obviously a lower case character and an upper case character will have a different key code. The problem is that regardless of whether the lowercase key code or the upper case key code is used, the character is inserted as lowercase in a WinForms text field. REPRO 1. Run the attached script 2. When warned, put the cursor inside of a WinForms text box (I use uia2atk/test/samples/textbox.py) 3. Wait for the script to finish RESULTS "cc" will be inserted into the text box EXPECTED RESULTS "cC" should be inserted into the text box COMMENTS You can duplicate the REPRO steps using a Gtk text field instead of a WinForms text box to verify the expected results.
Created attachment 283539 [details] test script referenced in REPRO steps
This issue also seems to include any time when the shift key would be pressed on a physical keyboard. That is, it does not only happen when attempting to generate capital letters, but it also occurs for symbols. For example, attempting to generate a "(" will result in a "9", a ")" will result in a 0, and so on. I am changing the bug summary slightly to more clearly indicate this.
Hey, Brian, I got "cC" on my machine. (In the status of no modifier key is pressed). Anyway, we can still easily find bugs when any or multiple modifier keys are pressed.
I thought it's a common problem when people trying to input some text with automation on X Window. Basically the logic would be implemented as following: //try to input a character c c_keycode = get_keycode_of (c) needShift = if_shift_needed (c) if (needShift) SendKeyEvent(shift_keycode, pressed) SendKeyEvent(c_keycode, pressed) SendKeyEvent(c_keycode, released) if (needShift) SendKeyEvent(shift_keycode, released) However the upper code will only work when no modifier key is pressed. If any modifier key is pressed, (including the shift key that Brian has mentioned, and also Capslock, NumLock, Alt, Ctrl, ModN etc...). So the only solution I can suggest is to firstly remember modifier keys states, then release all the modifier keys, and then do the former pseudo code, then recover the modifier keys states. But this suggestion may have side effects in some situations, since we may need to generate a bunch of key events to release/recover the modifier keys, and also I'm not sure whether there'll be any problem if the end-user presses a modifier key on a physical keyboard. BTW, related bugs in other ops project: http://code.google.com/p/semicomplete/issues/detail?id=4 http://code.google.com/p/semicomplete/issues/detail?id=6
Update work hours