GNOME Bugzilla – Bug 138391
Layer 0 'goto status bar/goto toolbar' broken
Last modified: 2004-12-22 21:47:04 UTC
using gnopernicus from CVS HEAD 29 Mar -launch gnopernicus -launch nautilus -'KP 0, KP 0' to change to layer 0 -'KP 3' to 'goto status bar' -'KP 1' to 'goto toolbar' .gnopernicus does not output information on these objects. The output received is that of a window switch: 'switched window, file-browser, <currently selected object>'
For me this bug has exactly same behaviour like bug 134003.
David: please indicated the applications in which this bug is present, i.e. does it happen for all apps, or only some apps/situations? Thanks.
This happens in gnome-terminal, gedit and nautilus. It seems to be all the time,everywhere.
I reproduced this bug in gedit and nautilus but I am not so sure this is exactly the same behaviour like bug 134003. In this situation the layer can be changed. If I press key '0' from numpad I don't see the unwanted focus event (like in 134003). So after 'KP 0, KP 0' I managed to switch to layer 0. Also, goto toolbar/goto status bar actions are not actually broken (even if gnopernicus does not output information on these objects). To check this, I applied the patch proposed by Remus on bug 122713, comment #19 (patch to log all outputs sent to speech) and I run gnopernicus with GNOPERNICUS_LOG set to at-spi: After 'KP 1' the toolbar description is sent to speech. But at this point two unwanted events occure: a 'window:activate' event followed by a 'focus:' event for the currently selected object. (Some behaviour for 'KP3') Beacause of this two events the output is that of a window switch: 'switched window, file-browser, <currently selected object>' and the status bar/toolbar description is not outputed.
Changing the layer and executing a commnad from a layer is same thing from at-spi point of view, the difference is only internal in gnopenicus (how a key press is interpeted). Dana's obsevations about unwanted events ("window:activate" and "focus" after a press of a numpad key) are sustaining my oppinion that this bug is a duplicate of 134003. Closing bug as dupicate of 134003. *** This bug has been marked as a duplicate of 134003 ***
*** Bug 141431 has been marked as a duplicate of this bug. ***
we need a test program again, since the one in 134003 doesn't apply here (that problem was confirmed fixed).
severity is not 'critical', marking 'major'. "Major" means basically useless, whereas "critical" means data loss, etc.
While using gedit with gnopernicus and pressing KP0 KP0 and KP3 I see: <SRSOUT priority="0" preempt="true"><TEXT voice="system">layer 0</TEXT></SRSOUT> <SRSOUT priority="0" preempt="true"><TEXT voice="role">Status bar</TEXT><TEXT voice="name"> Ln 1, Col 1</TEXT><TEXT voice="name"> INS</TEXT></SRSOUT> <SRSOUT priority="2" preempt="true"><TEXT voice="system">switch to window</TEXT><TEXT voice="name">Untitled 1 - gedit</TEXT></SRSOUT> <SRSOUT priority="0" preempt="true"><TEXT voice="role">Multi Line Text</TEXT></SRSOUT> I will try to figure out what is going on.
The problem here is that gnopernicus is spending a lot of time in a keyboard callback. The solution is to report a keyboard event on a timer.
I got switching to statusbar to work by increasing the timeout in at-spi-registryd to 3 seconds. Remus, Can you show me what work gnopernicus does when switching to statusbar. Perhaps we can optimize what is being done either in gnopernicus or in gail.
Padraig, I don't believe this problem can be solved in gail because all calls are made in the callback. As Remus said, the problem here is that gnopernicus spend a lot of time in a keyboard callback. If the keyboard event is reported on a timer, the unwanted event doesn't occur. If you apply the following patch, the layer's commands are correctly executed.
Created attachment 27321 [details] [review] proposed patch
Created attachment 27331 [details] [review] new proposed patch
Comment on attachment 27331 [details] [review] new proposed patch Patch commited to CVS head.
We aren't quite completely fixed yet. Try flat review of the Gnopernicus Startup mode dialog. Doing this a whole bunch (NumPad 2 repeatedly to the bottom of the window, then NumPad 8 repeatedly to the top) will still cause Gnopernicus to drop out of flat review in response to a window switch event (it appears).
Peter: if you are talking about something that appears intermittently, under stress, then at some point it will be WONTFIX. There may well be no way to 100% reliably fix this without ruining performance/responsiveness. That said, one possibility is that the problem is caused by gnopernicus failing to return from the key notification in a timely fashion when it's busy doing something "expensive". So in the cases you mention above, we need to determine exactly what gnopernicus' stack looks like when it receives the key notifications, and also ensure that it doesn't go long periods without servicing the event listener. This latter (checking the event listener) will happen any time is makes an AT-SPI call on which it must wait; however the fact that the listener is in an idle handler means that there are no guarantees about the timeliness of responses to key event notifications. A "tardy" acknowledgement of a key event will result in one of these window switch events. There is no way in glib/gtk+ to guarantee a maximum time between "idle", "timeout", or "timer" handlers, by the way. And even if gtk+ tried to provide this, it's impossible to guarantee given the nature of the Linux scheduler.
I wouldn't be surprised if Gnopernicus doesn't return very quickly here; the event handling changes will hopefully address that. Further, a switch to XEvIE should likewise fix this bug. Therefore, after an audit of Gnopernicus to make sure it is returning as quickly as possible, I'm happy to close whatever remains of this bug.