GNOME Bugzilla – Bug 343133
orca reliably hangs while trying to read a man page in terminal
Last modified: 2006-07-25 21:25:39 UTC
Steps to reproduce: 1. Open terminal and type man gedit 2. While the man page is being read press CTRL. 3. Attempt to flat review the screen with KP7 and KP9 Stack trace: orca hangs Other information: This happens with ubuntu dapper latest as of 05/27/2006 and latest orca from the same time.
I've been able to reproduce this on my machine. It looks like this is causing a hang in gnome-terminal - if I kill gnome-terminal, Orca comes back to life. I also wonder if this is possibly related to the minicom problem (http://bugzilla.gnome.org/show_bug.cgi?id=342840). While that one seems to hang the desktop, killing gnome-terminal in that case also seems to free things up.
The same happens when you press a "(" or a ")" and then trying to flat review the screen. Has to be with some characters set, and this happened too with Orca 0.2.3. Something has changed in the latest gnome-terminal app.
Created attachment 66535 [details] [review] Patch to break out of flat review logic if gnome-terminal is acting up The AT-SPI implementation was giving us nonsensical values for getTextAtOffset, causing a hang in subsequent calls. This patch provides a defensive mechanism against those types of problems.
From Javier: > I have recently updated my cvs copy of Orca fixing the bug #343133. > However Orca or gnome-terminal continue hanging when flat reviewing teh > Gnome-terminal and man pages, for example > Man brltty. > When this happends, Orca keep queueing all events on the system, and then > when gnome-terminal is killed, Orca dies cause flat review can't do its > purpose, at this point > a traceback error on flatreview.py on line 1396 is made. Please verify that you have (and have installed) the fix in question. One way to check would be to look at line 1092 of /usr/lib/python2.4/site-packages/orca/flat_review.py. If you have installed the fix, the file will have the following at line 1092: # (see http://bugzilla.gnome.org/show_bug.cgi?id=343133), If you do have this, please attach the details of the traceback - they can be helpful in debugging the problem. Thanks!
Created attachment 68075 [details] [review] More work to handle bogus results from gnome-terminal More defensive programming to detect nonsensical and handle values from gnome-terminal. The test case for this was "man brltty" followed by a KP_7 for flat review.
I just tried this and don't see any hangs. What I do see is that when I've hit KP9 on the last object in the gnome-terminal window (typical the --More-- (nn%) line), there is no indication that this is the last object. Should there be?
Not really, this is just the end of the window. At some point we might want to say bottom of window and top of window but not for 1.0 necessarily.
This appears to now be solved. Closing as FIXED.