GNOME Bugzilla – Bug 432308
[blocked] Problem with Evolution and threads always speaking "expanded 0 items".
Last modified: 2012-08-14 21:24:32 UTC
From Lorenzo on the Orca mailing list: This may be a bug in Evolution, but I thought I'd bring it to the attention of the list in case it may be an Orca issue or maybe Evolution developers can shed some light on the issue. Whenever I have a group of messages in a thread Orca speaks "expanded 0 items" no matter how many messages are in the group. It would be helpful to have Orca speak the actual number of messages in the thread rather than 0 items every time. I should note here that "expanded 0 items is only spoken when there is more than one message grouped in a thread.
Yes, this is a bug in Evolution. All the table cells in the message header tree table are at level 0. at-poke shows up this. I'll file an Evolution bug on this, and block this bug against it.
I've filed Evolution bug #433019 on this. http://bugzilla.gnome.org/show_bug.cgi?id=433019 Blocking this bug against that one.
Removing target milestone from [blocked] bugs. We have little control over them, so we're better off letting priority and severity be our guide for poking the related components.
The Evolution team seems to be AWOL wrt a11y bugs. Any possibility we can work around this problem? For example, maybe just don't present the "0 items" part?
Created attachment 102926 [details] [review] Revision #1 Here's a first attempt to work around this bug in the Evolution script: If this is the first message in a thread, try to determine the number of messages in this mail thread and return the correct utterances. If cell's subject doesn't start with "Re:", it is considered to be the first message. Otherwise it'll just strip off the "0 items". Note that it will only do the following if you have "read by row" enabled and you are moving up or down in the message header list.
Just gave this a try. It is definitely a huge improvement! A couple of observations: 1. I arranged my bugzilla folder by thread. Nothing in the subject of any of those messages says "Re:" so Orca announces the presence of 1 item only. 2. Sometimes the first item in a thread starts with Re, either because you started the thread or because you've deleted earlier messages.
Yup. I know. It's not a perfect solution. It's a hack to try to work around yet another Evolution bug. From your two observations above, we could probably add code to improve/solve 2, but not 1. The question is, where do you stop hacking at the script to try to prevent borkage in Evolution? Mike/Will, what would you like to see here?
Oh, I should have added what you would need to do to improve/solve 2. In this case, you don't know if it's the first message in the thread or not. So you would need to look both backwards and forwards and see if the subject was the same as the current cell's subject in order to determine the number of messages in that thread. Even then, the previous/next message might be in a different thread but have the same subject. Like I said, where should you stop hacking at the script to try to prevent borkage in Evolution? Will's original suggestion was just to remove the bogus "0 items" after "expanded". That's quite easy. I tried to do something different. Note also that if we wanted to remove "0 items' if we are in "speak by cell", then we would have to have a new SpeechGenerator class for the Evolution.py script and basically crib the whole of the _getSpeechForTableCell() method (127 lines) except for adjusting the bit that deals with "0 items". Like I said, where should you ... yada yada yada ...
Created attachment 102941 [details] [review] Revision #2 We discussed this in the Orca team meeting today. The plan now is to just adjust the _getSpeechForTableCell() method in speechgenerator.py to not speak "0 items". Revised patch attached.
OK - so I did some digging. We have a couple related bugs: bug 456970: Orca says "0 items" for tree tables that use NODE_CHILD_OF relationship bug 319666: Empty tree tables should announce themselves as empty So, maybe we're being too overzealous by removing this from default.py if this ends up re-breaking 319666. Darn if it does. If it does cause a regression, we might need to go down the 'fix it in Evolution.py' route. It might be possible to fix it in Evolution by first calling the super class's speech generator and then stripping out the last utterance if it we can detect the object is in the condition/state that would have caused the default.py speechgenerator to put "0 items" in there.
Created attachment 102945 [details] [review] Revision #3 Implements what Will suggested in the last comment.
Adding back "[blocked]" as we will still now need the Evolution bug to be fixed.
This works for me. It also seems to address an earlier issue you pointed out, namely: > [...] Note that it will only do the following if > you have "read by row" enabled and you are moving up or down > in the message header list.
Right. This is a more generalized solution that will work irrespective of the table cell read row/cell setting. We could get it even tighter and check the role hierarchy in _getSpeechForTableCell(), to make sure we are in a message header list, but I suspect that's the only place where there are broken expanded states and hence "0 items". Thanks for trying it.
(In reply to comment #14) > Right. This is a more generalized solution that will work irrespective > of the table cell read row/cell setting. > > We could get it even tighter and check the role hierarchy in > _getSpeechForTableCell(), to make sure we are in a message > header list, but I suspect that's the only place where there > are broken expanded states and hence "0 items". I'm fine with the current patch, but would welcome a more restrictive patch that does the 'are we in the message header list?' check. I'll leave that decision to you. :-)
> We could get it even tighter and check the role hierarchy in > _getSpeechForTableCell(), to make sure we are in a message > header list, but I suspect that's the only place where there > are broken expanded states and hence "0 items". I *believe* you are correct (from my recollections of bug 456970). But hypothetically, if there is some other place in Evolution with broken expanded states and hence "0 items," would we want to announce "expanded 0 items"?
The question is more of whether there is a legal place within Evolution where a table cell with an expanded state can have 0 items. I don't know. Like Will, I think it would be better if we tightened this up to just do this currently for the message header list. New patch later today. Thanks.
Created attachment 103001 [details] [review] Revision #4 Patch tightened and committed.
Removing the "[testing required]". Back to just being "[blocked]".
*** This bug has been marked as a duplicate of bug 433019 ***