Bug 491282

Summary:	pyatspi.Registry.generateKeyboardEvent incorrectly types keys that are typed using the shift key
Product:	[Mono] UI Automation	Reporter:	Brian Merrell <bgmerrell>
Component:	Winforms - General	Assignee:	E-mail List <mono-a11y-bugs>
Status:	CONFIRMED ---	QA Contact:	E-mail List <mono-a11y-qa>
Severity:	Normal
Priority:	P3 - Medium
Version:	Release 1.0
Target Milestone:	Release 1.1
Hardware:	x86
OS:	Linux
Whiteboard:
Found By:	Integration Test	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	test script referenced in REPRO steps

Description Brian Merrell 2009-04-01 21:01:20 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.

Comment 1 Brian Merrell 2009-04-01 21:07:58 UTC

Created attachment 283539 [details]
test script referenced in REPRO steps

Comment 2 Brian Merrell 2009-06-10 17:36:50 UTC

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.

Comment 3 Rui Guo 2009-07-02 18:48:44 UTC

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.

Comment 4 Rui Guo 2009-07-02 19:07:10 UTC

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

Comment 5 Rui Guo 2009-07-17 16:56:48 UTC

Update work hours