GNOME Bugzilla – Bug 567864
Orca stops responding when flat review is used in thunderbird message window and message is closed
Last modified: 2009-01-21 23:33:38 UTC
Please describe the problem: If flat review of orca is used in a message viewer window of thunderbird 3.0b1 when you exit the message orca will stop responding until a mouse click is performed. Steps to reproduce: 1. open a message in thunderbird to read it. 2. Use flat review keys. 3. exit message (control+w or alt+f4) Actual results: Orca stops responding until a mouse button is pressed on the mouse. Expected results: Orca would just continue to work as normal (eg. speak the item in the message list selected if exiting the message would return focus there). Does this happen every time? Seems to, even if you do non-flat review actions after using flat review before you exit the message (it seems to only require that you use flat review at some point while the message is open). Other information: This is using thunderbird 3.0b1, I don't know if it is so on other versions of thunderbird. Also from what I can tell, other actions are not occuring (eg. while orca is not responding I cannot minimise the windows to reveal the desktop). I don't know if it is only orca causing this, but orca flat review certainly seems to be something which will make it happen.
I'm using 3.0b2pre with the same problem.
I'm having trouble reproducing this. :-( Can you please post a debug log per the instructions at http://live.gnome.org/Orca/Debugging? Please keep in mind the debug log will contain everything you view and type, so don't type any passwords and don't read any mail you might consider private.
I see the same behaviour in Evolution version 2.24.2 and Orca 2.24.1. What seems to happen is that the Flat Review continues active after the Window closes (a sighted friend tells me you can see the review cursor). The problem is that the focus remains with Flat Review but you can't do anything with it, so you need to change focus with a mouse click. As discussed in the list, kpd_minus doesn't do anything.
(In reply to comment #3) > I see the same behaviour in Evolution version 2.24.2 and Orca 2.24.1. > > What seems to happen is that the Flat Review continues active after the Window > closes (a sighted friend tells me you can see the review cursor). > > The problem is that the focus remains with Flat Review but you can't do > anything with it, so you need to change focus with a mouse click. > > As discussed in the list, kpd_minus doesn't do anything. Aha! OK. We might be able to handle this by destroying the flat review context if we detect a window closing. I'm just making a note of this to remind myself to try that out.
Created attachment 126562 [details] output debug from orca
although the bug was reported originally to happens in thunderbird, I have observed the same behaviour in pidgin when composing a message and using the flat review.
Created attachment 126758 [details] [review] Patch to fix the problem This patch seems to resolve the problem nicely. The problem was in fact that the flat review context was not being destroyed when the window was being killed.
Sorry this patch doesn't seem to solve it for me. I first did an svn update and noticed that the changelog said this patch was included (r4431) when compiled and installed that didn't work, tried going back to r4430 and patched it with the patch file from here and compiled and installed, still no success. I have also noticed that I can unlock the system by switching to a text console and entering orca -q to exit orca and then when I restart orca things are fine. This seems to match with the comment that it is flat review not exiting. (In reply to comment #7) > Created an attachment (id=126758) [edit] > Patch to fix the problem > > This patch seems to resolve the problem nicely. The problem was in fact that > the flat review context was not being destroyed when the window was being > killed. >
(In reply to comment #8) > Sorry this patch doesn't seem to solve it for me. I first did an svn update and > noticed that the changelog said this patch was included (r4431) when compiled > and installed that didn't work, tried going back to r4430 and patched it with > the patch file from here and compiled and installed, still no success. I verified this worked by performing the exact steps provided in the opening comment. I also verified it by testing with the gnome-terminal preferences dialog (i.e., open preferences, flat-review it, press alt+f4 to close it). Can you describe more about what you did to verify it didn't work? In addition, you might be in patch purgatory in some way. Can you please make sure that the onWindowDeactivated in the version of default.py that you have installed has a line that contains "if self.flatReviewContext:" in it? In r4431, it would be at line 4183.
(In reply to comment #9) > (In reply to comment #8) ... > > I verified this worked by performing the exact steps provided in the opening > comment. I also verified it by testing with the gnome-terminal preferences > dialog (i.e., open preferences, flat-review it, press alt+f4 to close it). > > Can you describe more about what you did to verify it didn't work? In > addition, you might be in patch purgatory in some way. Can you please make > sure that the onWindowDeactivated in the version of default.py that you have > installed has a line that contains "if self.flatReviewContext:" in it? In > r4431, it would be at line 4183. > I have checked that the actual installed files have the patch (I have updated to svn r4432) and I find the line "if self.flatReviewContext:" at line 4183. Also to confirm that I am using the right version when running orca I did a orca -v and it reports orca 2.25.5 (this contrasts to the slightly earlier version of orca 2.25.5pre I was getting with earlier revisions). What I am doing: Using thunderbird 3.0b1 I open a message (in this case the one reporting the last change to this bug report) I then use flat review and then press alt+f4. At this point everything freezes up until a mouse click or orca is stopped. I tried the gnome-terminal preferences example (I could only find profile preferences in gnome-terminal so used that) and I encountered no lock up. I then did flat review on the terminal window itself and immediately after flat review (no other keypresses between flat review keys and alt+f4) I exited gnome-terminal with alt+f4, and the system locked up again. Shall I produce a debug log?
Hi Michael: Perplexing. :-( Can you try testing with trunk and the uncommitted patch at http://bugzilla.gnome.org/show_bug.cgi?id=561548#c12? If that fails, please do attach a debug.out file. Thanks!
(In reply to comment #11) > Hi Michael: > > Perplexing. :-( Can you try testing with trunk and the uncommitted patch at > http://bugzilla.gnome.org/show_bug.cgi?id=561548#c12? If that fails, please do > attach a debug.out file. > > Thanks! > That patch applied to r4434 seems to fix it for me (in thunderbird, in gnome-terminal and firefox, possibly more but I haven't paid attention to whether the bug occurs elsewhere or tested them yet (that shows how infrequently flat review needs to actually be used)).
Works fine for me. I didn't test with pidigin yet, another place where the problem happens frequently.
Committed to gnome-2-24 for Orca 2.24.4.
This patch also didn't work with my orca 2.24.1. After the patch I continued to see the behaviour in evolution I described in my first comment. In gnome-terminal Profile Preferences, I have no problems even without any patch. Like with Michael, the patch in Bug #561548 seems to fix it. Shouldn't this bug be made a dyplicate of that one? Or at least have the same patch attached to both bugs?
(In reply to comment #15) > This patch also didn't work with my orca 2.24.1. > > After the patch I continued to see the behaviour in evolution I described in my > first comment. > > In gnome-terminal Profile Preferences, I have no problems even without any > patch. > > Like with Michael, the patch in Bug #561548 seems to fix it. > > Shouldn't this bug be made a dyplicate of that one? Or at least have the same > patch attached to both bugs? > The comments cross reference each other and both are closed as fixed. Thanks!