GNOME Bugzilla – Bug 347964
[a11y] When deleting messages in Evolution, Orca initially speaks the wrong tree item
Last modified: 2007-04-20 19:23:44 UTC
Please describe the problem: Given a list of messages in Evolution, deleting the current item results in the next item in the list receiving focus. The problem is that Orca initially speaks the item AFTER the item that just received focus. Having done so, then it speaks the item that received focus. Steps to reproduce: 1. In Evolution's Inbox, navigate to a message (X) that has at least two messages after it (Y and Z). 2. Press Delete to delete X Actual results: Y gets focus, but Z is spoken. After Z is spoken, Y is spoken. Expected results: Orca would only speak the row of the message which received focus (i.e. Y) Does this happen every time? Yes. Other information: This is only with speech. My braille display shows the correct information. I'm using the current (7/18) CVS build of Orca.
I've just successfully recreated this. The problem is that when you delete the X'th message, the Z'th message is getting a "focus:" event and section "3)" in the locusOfFocusChanged() routine in Evolution.py is processing it. Then we are getting a "focus:" event for the Y'th message and the same section of code in Evolution.py is then handling that. I don't believe that Evolution should issue a "focus:" event for the Z'th message. Only for the Y'th message. Will, if you agree, then I'll reclassify this bug under Evolution.
The behavior is certainly very very bizarre. I'd say reclassify to Evolution to see if they can eliminate the interim/spurious focus event. Thanks!
Reclassifying to Evolution. We were testing against Orca in CVS HEAD. I will attach a transcript of the debug messages that I saw generated by the Orca Evolution.py script while I was testing this out.
Created attachment 69366 [details] Transcript of the Orca events for the problem. Here's what happening in the Orca event transcript. * Lines 1 and 10. The Down arrow press/release to get focus onto the X'th mail message. * Line 16. The "focus:" event for that message. You can see the SPEECH output at line 35. * Lines 218 and 225. The Delete key press/release for the X'th message. * Line 237. The "focus:" event for the Z'th message. This gets (incorrectly) spoken at line 258. * Line 277. The "focus:" event for the Y'th message. This gets spoken at line 298. These debug messages were obtained by making the following changes to the Evolution.py script, then reinstalling Orca: * At line 60, change: self.debugLevel = debug.LEVEL_FINEST to: self.debugLevel = debug.LEVEL_OFF * At line 314, uncomment: util.printAncestry(event.source) Thanks.
I can not reproduce this with Evolution trunk, after I deleted X, orca just speaked Y twice. But it can be reproduced in 2-14b.
Okay, thanks Li! I think you can close out the bug as fixed then. Will this fix be in the Evolution that goes into GNOME 2.16?
Rich: I'm investigating this bug. I have a question about Orca. When I press arrow key to go through the message-list, I found if I press the key quickly enough, the sound of next message will interrupt the previous one. Back to this bug, Evolution emit two focus events, why Orca will read the second focus message after it finish the fisrt one? I think the first one should be interrupt.
(In reply to comment #7) > Rich: I'm investigating this bug. I have a question about Orca. > When I press arrow key to go through the message-list, I found if I press the > key quickly enough, the sound of next message will interrupt the previous one. > Back to this bug, Evolution emit two focus events, why Orca will read the > second focus message after it finish the fisrt one? I think the first one > should be interrupt. Orca currently interrupts speech when the user types on the keyboard and will also do so when one closes the window from which Orca is speaking an object. For a number of reasons, however, Orca currently doesn't automatically interrupt speech when it gets a focus event. One reason is that there may be other speak operations going on, such as Orca reporting the current window title as the result of a window activation event. We don't want to lose that information. Post GNOME 2.16, we plan on investigating refactoring the speech support for Orca to be able to put some sort of priority queue in place as well as reasons for why something is being spoken. In this, we could potentially handle strangeness such as spurious focus events happening, but it would be much better if these kind of events were not issued unless they were really supposed to be issued.
I tested Evolution with at-poke by loging Evolution's focus event. There are 3 mails in my inbox, 1st one is "aaaaaa", 2nd is "bbbbbb", 3rd is "ccccccc". At first focus is on "aaaaaaa", and I press delete, orca speak "cccccccc" and then "bbbbbbb". But in at-poke's events log, it shows two focus events are both from "bbbbbbbb". Here is log: generic event 'focus:' A|co|ac|te|ed:table cell:aaaaaa:(0) (0) generic event 'focus:' A|co|ac|te|ed:table cell:bbbbbbbbbbbbbbb:(0) (0) generic event 'focus:' A|co|ac|te|ed:table cell:bbbbbbbbbbbbbbb:(0) (0) The first focus is emitted when Evolution window get the focus.
I was just looking at this and see exactly what Li is seeing. Both focus events are indeed for the same message. BUT, the first focus event contains the index of that message *prior* to the deletion. The second focus event contains the index of that message *after* the deletion. Orca seems to be handling both focus events post-deletion thus we first hear "ccccccc"/Z and then hear "bbbbbbb"/Y. This problem is still present in Evolution 2.9.6/GNOME 2.17, by the way. Re comment #5, on occasion I see the double-speaking of Y, rather than of Z followed by Y, but it's not the norm.... It's still typically Z followed by Y.
So, Will, I'd like to transfer this bug back to Orca, because at-poke give us the right information.
(In reply to comment #11) > So, Will, I'd like to transfer this bug back to Orca, because at-poke give us > the right information. Joanie - what do you think? Does this bug still exist?
> Joanie - what do you think? Does this bug still exist? It definitely still exists. :-( I would agree with Li that it's not an AT-SPI bug, though. Rather, this is an Evolution bug and/or something we should try to work around. On the Evolution side of things, if we only got a focus for the message post-deletion, I bet we'd speak the correct item right off the bat. :-) BTW, Rich included this bug in his list of Evolution bugs that he passed along to the Evolution folks a couple of weeks ago. Hopefully they are looking at it....
That'll teach me to comment first and then view the bug activity. I just assumed since Li was commenting that he was transferring it from AT-SPI back to us. Oops. Li: Would it be possible to cause Evolution to just generate one focus event rather than two, and to generate that event post-deletion?
I haven't got time to look into the code. But from the GUI, I think the first event generated when some message was marked as deleted, because Evolution moved the focus to the next message. The second event generated when Evolution try to refresh the folder to hide the deleted message. If you un-check "Menu->View->Hide Deleted Message", you will see only one event.
> try to refresh the folder to hide the deleted message. If you un-check > "Menu->View->Hide Deleted Message", you will see only one event. Confirmed.
Created attachment 86494 [details] [review] possible work-around This patch seems to address the "speaking the wrong tree item initially" problem. NOTE: With the patch, **if** show deleted items is enabled, nothing will be spoken when you delete a message. This seems to be one of those no-free-lunch things. Here's my personal take: I suspect that most of the time users won't be showing deleted items within their Inbox and other folders. It's additional clutter in and of itself -- even more so given that (as best as I can tell) there is nothing distinguishing deleted messages from non-deleted messages via AT-SPI. If a user has enabled the showing of deleted messages, he/she has likely done so in order to recover a deleted message and will disable that setting once this goal has been achieved. Therefore, I think that the cost is worth it because it improves what we do under "normal" circumstances. But that's just me. Assuming y'all agree.... Rich: Given how many situations the Evolution script handles, I'd appreciate your looking it over when you have the opportunity just to be sure that I didn't break something in the process. Thanks! (I still think we should only be getting one focus event, however. :-) )
This doesn't look too bad. I wish there were some other way to detect that we were about to speak something odd. When I look at a debug.out, I see something like this in my "focus:" event. In this case, Darragh is the message that follows Willie, and I just deleted the message prior to Willie: vvvvv PROCESS OBJECT EVENT focus: vvvvv OBJECT EVENT: focus: detail=(0,0) app.name='evolution-2.10' name='Willie Walker <William.Walker@Sun.COM>' role='table cell' state='ENABLED FOCUSABLE FOCUSED SELECTABLE SENSITIVE SHOWING TRANSIENT VISIBLE' relations='' .... SPEECH OUTPUT: 'Darragh <lists@digitaldarragh.com>' ... BRAILLE LINE: 'unread From Darragh <lists@digitaldarragh.com> Cell [orca-list] Evolution. 5:52 AM ' VISIBLE: 'From Darragh <lists@digitaldarra', cursor=1 ^^^^^ PROCESS OBJECT EVENT focus: ^^^^^ Note that the name of the cell and what is spoken seem to be different. I'm not sure if this is of any use or if it happens consistently, though.
> Note that the name of the cell and what is spoken seem to be different. I'm > not sure if this is of any use or if it happens consistently, though. It's definitely of use, but the consistency bit is the issue I think. :-( I'm not seeing what you're seeing in my focus: event. I was on a Bugzilla message which I deleted. I landed on a message from Peter Sullivan. But first a message from Rich was spoken. The name of the cell is Rich-related. (Which undoubtedly makes all of this Rich's fault ;-)) vvvvv PROCESS OBJECT EVENT focus: vvvvv OBJECT EVENT: focus: detail=(0,0) app.name='evolution-2.10' name='Rich Burridge <Rich.Burridge@Sun.COM>' role='table cell' state='ENABLED FOCUSABLE SELECTABLE SENSITIVE SHOWING TRANSIENT VISIBLE' relations='' LOCUS OF FOCUS: app='evolution-2.10' name='Rich Burridge <Rich.Burridge@Sun.COM>' role='table cell' event='focus:' .... SPEECH OUTPUT: 'Rich Burridge <Rich.Burridge@Sun.COM>' .... SPEECH OUTPUT: 'Re: [orca-list] Orca on latest Debian' .... SPEECH OUTPUT: 'Yesterday 4:03 PM' BRAILLE LINE: 'From Rich Burridge <Rich.Burridge@Sun.COM> Cell Re: [orca-list] Orca on latest Debian Yesterday 4:03 PM ' VISIBLE: 'From Rich Burridge <Rich.Burridg', cursor=1 ^^^^^ PROCESS OBJECT EVENT focus: ^^^^^
Wait wait wait: Looking at yours: Yours is focused. Looking at mine, Peter Sullivan is focused. Rich is not focused (you know what I mean). Let me see if this is reliable.
Unfortunately that seemed to be a fluke. Now the names are matching, everyone's focused, etc. :-( I'm wondering if it's a timing issue?
> Unfortunately that seemed to be a fluke. Now the names are matching, > everyone's focused, etc. :-( > > I'm wondering if it's a timing issue? Probably. Oh well. It was worth a shot. I say your current patch is better than what we were getting, and the limitation is a bad nuisance rather than one that might cause you to accidentally delete mail (like this bug). So...check it in? What do you say, Mike?
I spent my lunch break trying to come up with other clever (or not) alternatives. None presented themselves I'm afraid -- though I am certainly open to other possibilities.
I agree, I really don't think most users view there deleted messages in the inbox anyway. I think the patch should be committed.
Patch committed.
Created attachment 86651 [details] [review] check if we just deleted a message before deciding we don't want to speak the whole row. In the Evolution script, some bogusity is being handled by temporarily setting readTableCellRow to False and resetting it to True at the end. Seems we need to include whether or not a message was just deleted as part of determining the value of speakAll. Mike, does this solve the problem for you?
Looks great. thanks much
Thanks for the test. Rich/Will, seem okay to check this in?
Looks okay to me. Thanks for doing this.
Thank you for looking it over. Patch committed.
*** Bug 419141 has been marked as a duplicate of this bug. ***
This looks good. OK to close.
Closing as FIXED -- though I stand by my statement that we really should only be receiving one focus: event :-)