GNOME Bugzilla – Bug 371588
dogtail-recorder problems with FC6 and keyboard navigation
Last modified: 2011-02-07 06:07:34 UTC
Please describe the problem: Installed Fedora Core 6, did 'yum update'. Checked out dogtail from CVS and installed it. Invoked a typical GUI application and also dogtail-recorder. Attempt to use application via keyboard navigation and dogtail-recorder emits many error messages. Steps to reproduce: 1. Invoke 'gtk-demo &'. Invoke 'dogtail-recorder &'. 2. Click the 'record' button in dogtail-recorder, then click the top bar of the gtk-demo window to acquire focus. Hit the down arrow key a few times. 3. Many error messages are emitted. However if you mouse-click on a table item in the lefthand pane of gtk-demo and then hit an arrow key it will begin working. as expected. Actual results: #!/usr/bin/python from dogtail.procedural import * Traceback (most recent call last):
+ Trace 83648
try: recorder.onKeyPress(event)
self.lastFocusedNode.text = self.lastFocusedNode._FakeNode__node.text
r__ return self.__text.getText(0, 32767)
ILURE:1.0" Traceback (most recent call last):
ILURE:1.0" Traceback (most recent call last): File "/usr/bin/dogtail-recorder", line 837, in marshalOnKeyPress try: recorder.onKeyPress(event) File "/usr/bin/dogtail-recorder", line 730, in onKeyPress self.lastFocusedNode.text = self.lastFocusedNode._FakeNode__node.text File "/usr/lib/python2.4/site-packages/dogtail/tree.py", line 538, in __getatt r__ return self.__text.getText(0, 32767) Expected results: The usual series of recorded keyboard commands. Does this happen every time? Once you click on some things inside the application window with the mouse, the recorder appears to 'synch up' and behaves normally. You can then kill the GUI application, bring it up again, and it will still behave normally. However if you exit dogtail and start both up from scratch the problem reappears. Other information: We suspect the cspi extension needs updating?
I'm not sure exactly how the dogtail keyboard recorder works, but this bug might be related to the change in how applications indicate focus changes in GNOME 2.16 versus 2.14. Previously, focus: events were fired for all focus changes in an application. Now, sometimes focus: events are fired, and other times object:state-changed:focus events are fired. It appears that focus: events are used when moving focus: within a window and giving focus to an object for the first time in a window. The other event is used when focus is "restored," meaning when a window is reactivated and the last focused control in that window is given focus again.
The recorder in CVS HEAD listens for the 'focus:' event. I tweaked it in a local checkout to additionally listen for 'object:state-changed:focus', but it seems that neither event is being fired. Can you point me to the list of changes you're looking at? I'm not finding anything relevant.
> Can you point me to the list of changes you're looking at? I'm not finding anything relevant. If you mean a listing of changes in the use of atk/gail in gtk, then I'm sorry to say I don't think one exists. We found this out by regression testing and experimentation in LSR. Typically, changes in how applications are firing events come as a surprise. :(
Then, I'm inclined to say that the real problem is this regression in atk or gail, and that we should reassign this bug to one of those components. It's not nice to pull events out from under apps like this. :(
This might be gail, but it is just as likely that the root cause could be a change in gtk+. There was no premeditated change to the way gail fires its events. Every focus: event should be accompanied by an object:state-change:focussed event. If it is not, then that is indeed a bug (which again, may or may not be in gail - to diagnose, one needs to identify the widgets/apps which demonstrate the problem). So - please do not reassign this bug without a test program which demonstrates the problem _outside_ of dogtail. Does the problem occur with the version of gtk+ used in gnome-2.16, run with a 2.14 desktop? If so, the problem is likely to be something triggered by changes in gtk+. I must say, the trace above doesn't point to gail at all, so I don't understand how the comments #2 - #4 relate to the initial description. Other clients such as orca are certainly seeing "focus:" and "state-changed:focussed" events, though I cannot confirm that both are always being fired as they should. I would suggest running a modified event-listener-test from at-spi (or another small event-listening client) to obtain an event log to confirm the event stream. Your report that "neither event is being fired" suggests some other/deeper problem which may be specific to your setup (otherwise the orca team would be seeing it).
Will Walker was first to report the lack of "focus" events in some cases for GNOME 2.15. See the comments in bug #350854 - "Orca should handle object:state-changed:focus events"
Has anything further been done on this? I recently updated my dogtail installation (extracted from CVS head) and now I get a different traceback when I try to use dogtail-recorder. To reproduce; invoke the recorder as a background process, invoke gedit, click the record button, acquire focus on the gedit panel, hit alt-f to bring up the 'files' menu. bash-3.1$ gedit GTK Accessibility Module initialized Bonobo accessibility support initialized #!/usr/bin/python from dogtail.procedural import * Traceback (most recent call last):
+ Trace 93315
self.writer.recordKeyCombo(modString + key, type, self.lastFocusedNode)
self.setUpFocus(node)
application = FakeNode.findAncestor(node, roleName = 'application')
while node.parent:
I think the issue is that more granularity was added and ATs on GNOME need to deal with the new/changed information. Orca and LSR have already adjusted for GNOME 2.16. Is Dogtail supported on FC6 and RHEL5 with GNOME 2.16?
We have replaced the yum installed Dogtail on our FC6 with code from CVS HEAD. Working from the upstream code seems to resovle the issue. Please reassign this bug to Fedora so that they will update the dogtail package for FC6.
dogtail development has been stalled and it has been unmaintained for a few years now. Maintainers don't have future development plan so i am closing bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development.