Bugzilla – Bug 450704
Incorrect list item is selected when issuing a click via pyatspi.Registry.generateMouseEvent
Last modified: 2009-07-14 16:08:23 UTC
PROBLEM STATEMENT Sporadically, when attempting to select a list item in a SWF ListBox using pyatspi.Registry.generateMouseEvent[1], the mouse cursor will go to the correct list item, but the incorrect list item (the list item below the list item that should be selected) is selected. This leaves the mouse cursor on the list item that I wanted to select, but the incorrect list item selected. I have tried to duplicate this on a physical machine, but have only been able to duplicate this issue in a VM (see comments) :( REPRODUCE I usually have better success duplicating the problem when I do not move my mouse when executing the step below: 1. Run the attached script with the path to the listbox.py sample as the only argument. For example, ./test.py /path/to/uia2atk/test/samples/listbox.py RESULTS Sometimes the the mouse cursor on the list item that I wanted to select, but the list item below it is actually selected. EXPECTS RESULTS The list item where the mouse cursor goes, which is the list item with the coordinates calculated in the attached script, should be selected always. COMMENTS Sorry, but I have no idea if it is even our stuff that is causing this bug and I do realize that the fact that I can only duplicate it in a VM could lessen its validity. However, I do know that I have not been able to duplicate this issue for Gtk. [1] Help on method generateMouseEvent in module pyatspi.registry: generateMouseEvent(self, x, y, name) method of pyatspi.registry.Registry instance Generates a mouse event at the given absolute x and y coordinate. The kind of event generated is specified by the name. For example, MOUSE_B1P (button 1 press), MOUSE_REL (relative motion), MOUSE_B3D (butten 3 double-click). @param x: Horizontal coordinate, usually left-hand oriented @type x: integer @param y: Vertical coordinate, usually left-hand oriented @type y: integer @param name: Name of the event to generate @type name: string
Created attachment 257092 [details] script referenced in the REPRO step
Add more comments: Today i have reproduced this issue once on my physical system by running the attachment script. but I can't reproduce it once more I update my VM to the latest rpms, I just can reproduce this issue once when each time the VM system being reboot
Okay, I am duplicating this issue on a physical machine every time I've tried it. It is an openSUSE 11.0 x86 install. I had to slightly modify the script; since the font on the physical machine is different, the '9' list item ended at the bottom of the window. I couldn't duplicate the issue until I modified the script to attempt to click a list item that had another list item directly below it. I will also attach a screenshot. I am also increasing the priority of this bug, but it's still possible it's not even our bug. To select list item 15 instead of list item 9, I changed lines 15 and 16 of the attached script (see Comment #1) 15,16c15,16 < list9 = pyatspi.findDescendant(ipy, lambda x: x.name == '9' and x.getRoleName() == 'list item') < extents = list9.queryComponent().getExtents(pyatspi.DESKTOP_COORDS) --- > list15 = pyatspi.findDescendant(ipy, lambda x: x.name == '15' and x.getRoleName() == 'list item') > extents = list15.queryComponent().getExtents(pyatspi.DESKTOP_COORDS)
Created attachment 257346 [details] Fuzzy photo of bug GNOME and Gimp screenshots didn't include the mouse cursor :P
Duplicated on a physical machine using: UIAutomationWinforms- 120364/ UIAutomation - 120012/ Mono - 120262/ UiaAtkBridge - 120352/ Gtk Sharp 2.12 - 2.12.7/ libgdiplus - 2.2pre/
P1s and P2s automatically go into Release 1.0.
I want to isolate the issue here and make sure it's us, so I've modified the script so it just prints out the x and y coordinates instead of moving the mouse there. (Incidentally, the mouse move/button click are completely at-spi/pyatspi methods and have nothing to do with us.) I've tried running said script about 30 times, and each time it's reporting the same values as accerciser is (which I know are correct as accerciser is drawing that friendly little red rectangle around the box). Brian or Calen, can you do the same thing and tell me if the bounding box values are changing? Thanks.
Hi Brad, the bounding box values aren't changing, also it's reporting the same x/y coordinates each time for Item15 for example. the problem is: we want to use "pyatspi.Registry.generateMouseEvent" select Item15, mouse cursor is moving to Item15, but Item16 is selected. list15 x y: 205 120 list16 x y: 205 133 BTW, incorrect selection just appeared in the first time to click, running the attachment which is add one click Item17(you can add more click other items) after click Item15 that Item17 will be selected correctly. is it at-spi/pyatspi's issue?
Created attachment 278628 [details] click two times
Hey Calen, Could you guys test this with Gtk+? I suspect this is an at-spi/pyatspi issue if we're returning the correct coordinates every time.
Hello Brad, I have tested this with gtkliststore.py, gtktreeview_noheader_nochildren.py and gtklist samples those are containing 1-20 tablecells as the same as listbox.py I modified , nevertheless, this issue doesn't be reproduced. :(
Hi guys, I can produce this bug on truck r134181. REPRO 1 Run the Comment #1 attached script (BTW, line 15 in test.py , "list item" shoule be placed by "table cell") with the path to the listbox.py sample as the only argument. For example, ./test.py /path/to/uia2atk/test/samples/listbox.py 2 Run ./test.py /path/to/uia2atk/test/samples/listbox.py again 3 change the test to select list item 1.( line 15 is changed to :"list9 = pyatspi.findDescendant(ipy, lambda x: x.name == '1' and x.getRoleName() == 'table cell')"), run the test.py 4 change the test to select list item 5, run the test.py 5 change the test to select list item 8, run the test.py RESULTS 1 list item 11 is selected .the output on screen :205 158 2 list item 11 is selected .the output on screen :205 158 3 list item 3 is selected .the output on screen : 85 118 4 list item 5 is selected .the output on screen : 85 198 5 list item 5 is selected .the output on screen : 85 198 EXPECTED RESULT 1 list item 9 is selected . 2 list item 9 is selected . 3 list item 1 is selected . 4 list item 5 is selected . 5 list item 8 is selected . COMMENTS the bug still exists
Move all P1 and P2 bugs into Release 1.1 milestone.