GNOME Bugzilla – Bug 747486
orca periodically loses focus on gnome terminal and will no longer read it's contents or pressed keys.
Last modified: 2015-04-22 16:10:44 UTC
Created attachment 301098 [details] debug file showing gnome terminal loss of focus This one is hard to reproduce consistantly. Sometimes when in gnome terminal, if you tab away from the application and use another for a while, when you tab back, orca will no longer see the window. It will no longer read typed characters or new text content. You cannot flat review nor bring up the menus. Attached is a debug log showing this behavior. The only fix seems to be restarting gnome terminal, which I have done in the debug file.
Using gnome3.14.3 and gnome-terminal3.14.2 thsi happens as well. On a fedora system using the latest gnome and gnome-terminal in fedora 21 (terminal3.14.3) this happens as well. I can either be using a terminal based app and it stops reading typed characters or it can happen randomly while trying to do basic shell commans in terminal itself.
The same problem here. I have no steps to reproduce. Sometimes, restarting orca solves the problem.
From your debug.out I see lots of cases where Orca is speaking terminal-related events. Is there a keypress or something else that I can search for in your debug.out to see that Orca is not presenting it or related text or focus events? If instead the problem is that gnome-terminal itself stops emitting events so Orca has no idea about the keys you're pressing and gets no text or focus or ... events, then the only thing I can do is try to narrow it down and file a bug against gnome-terminal for you. But I need steps I can reliably reproduce in order to do so.
Looking at my debug log it looks like orca is getting the terminal output, but no speech output events are logged, meaning orca does not actually speak what it's getting, but it's able to see it. The only semi reliable way to reproduce this would be to leave a gnome terminal application running that continuously produces output, or maybe an open file in a text editor? Open a few applications, just use your computer as usual. Periodically check back on the terminal window to see if orca can still read it. This is not at all helpful I know, and I apologize, I just don't know how to reliably make orca lose focus on the terminal, but it will eventually happen. The most reliable way I've found is to use a web browser, like firefox. If it helps at all, even newly typed characters aren't spoken, although orca will see them, and will even get the events from gnome terminal, it just won't speak the incoming text.
Can you provide an exact line number in which Orca got the output you wanted it to speak but did not speak it?
I've been trying for a few days to narrow it down to a specific line number. It's proving impossible. If this is at all helpful, this is application agnostic. So long as you're running something in a terminal and switch to a different app, orca will at some point lose focus on it. I'm not sure this is an orca issue, I'm stumped. I chose alter aeon because it produces a lot of text, and that seems to have something to do with how often this happens. I'm sorry for not being more clear, I'm usually better than this.When orca loses focus on gnome terminal, orca seems to be still getting the text caret moved events, and it is seeing the text, it's showing up in the debug logs but orca isn't speaking it, which is a little strange. I'll gladly give you any info you need, if I can, but this one is a weird one.
It seems that finally I managed to create a debug file in which the bug is present. Just search for string ( return ) in the attached file.
Created attachment 302153 [details] file in which orca loses focus on gnome terminal Just search for the string (return). The events are created by gnome-terminal but orca does not announce what is presented.
Thanks José!! We're getting closer I think. I just did a quick test in which I typed "hello" and pressed Return and Orca presented "command not found." Looking at my state set for that event, I see: state='enabled focusable focused sensitive showing visible' relations='' When I look at your debug.out, I see that you executed "pwd" and pressed Return and Orca did not present the directory. Looking at your state set for that event, I see: state='enabled focusable sensitive showing visible' relations='' Orca thinks the terminal object emitting the event is not focused. And as a general rule, events from objects you are not in should not be presented. If you can verify that when Orca does present text changes when the terminal object has state focused, and fails to present text changes when the terminal object lacks state focused, then we need to figure out what causes the terminal object to give up that state and never reclaim it. If you can find reliably reproducible steps triggering the state removal and never being returned even when the terminal is focused, I should be able to take that and file a bug against VTE. Thanks again!
Ok, I can reproduce the focus loss. I'll file a new bug against gnome-terminal.
*** This bug has been marked as a duplicate of bug 748311 ***