GNOME Bugzilla – Bug 582491
Strange message table behavior with Evolution
Last modified: 2009-11-09 21:35:26 UTC
I think this behavior happens whenever the folder which I'm highlighting in the folder list of Evolution receives a new message. Orca speaks the line of the table which I've highlighted last, and for some strange reason I am then unable to tab or otherwise move around the window I am in until I alt-tab to another window then alt-tab back. I think Orca might be attempting to read information for the newly-arrived message? If so, it's missing and instead reading the selected message again and again. Also, when last I used Thunderbird, this behavior was not present there so is a bit inconsistent across MUAs. A current workaround is to select a folder that will never receive new mail before alt-tabbing away from Evolution, then this behavior never happens. But since most MUAs can play sounds on incoming emails, or produce notifications, I'm not sure it is strictly necessary in Orca (assuming my diagnosis of where the problem originates is accurate.) I also don't see this strange table-reading behavior for the non-focused table anywhere else.
For completeness, please let us know which OS distribution and version you are using as well as the Evolution and Orca versions.
Ubuntu 9.04, Orca head, Evolution 2.26.1. I've seen this behavior in previous versions of Evolution, but since I only use Evolution as a last resort, I didn't report it then.
I'll investigate this one.
I can confirm several issues related to this bug. I did three tests: 1. Gave focus to a message in the list of messages and waited for an incoming message. 2. Same as #1 above, but I gave focus to a link in Firefox. 3. Same as #2 above, but I moved into some non-focusable text in Firefox (i.e. the opening report of this bug). Results: * In all three cases, when an incoming message was received, Orca spoke the currently selected message rather than the new one. * Unlike Nolan, I was able to Tab in trials #1 and #2 and things worked as expected. * In trial #3, Orca did not read the current text as I arrowed around. What seems to be taking place is this: Orca's not trying to read the new message; Evo is issuing a focus: event for the currently selected message and we're happily accepting it as valid -- and doing so whether we're in Evo or not. If the next action the user performs is to give focus to something else (e.g. with Tab) that typically results in a focus: event being issued so we're alright. If the next action does not result in a focus: event (e.g. arrowing around in Firefox text), we ignore anything that results from that action because the active script is Evo. Solution is presumably to identify this bogus focus: event and ignore it.
Any time a new message comes in, that new message steals focus. See Orca bug 483352: [blocked] New e-mail in Evolution can cause Orca to become unresponsive for a period of time. Note that the bug is blocked. That is due to Evo bug 483452: [a11y] Incoming mail steals focus from message composition window. Patch for the more serious issue (the incoming message causing Orca to not speak the focused app, like Firefox) coming up.
Created attachment 139662 [details] [review] Ignore bogus focus events when another app has focus This adds an isActivatableEvent method to the Evo script that ignores events if the window in which the event occured lacks STATE_ACTIVE. That should prevent the announcement if: 1. Some other app has focus 2. Some other window in Evo has focus (message, dialog) I believe it is the best we can do under the circumstances. :-( Will please review. Thanks.
(In reply to comment #6) > This adds an isActivatableEvent method to the Evo script that ignores events if > the window in which the event occured lacks STATE_ACTIVE. That should prevent > the announcement if: > > 1. Some other app has focus > 2. Some other window in Evo has focus (message, dialog) > > I believe it is the best we can do under the circumstances. :-( > > Will please review. Thanks. Hey cool! Another use for isActivatableEvent. Looks good and I say commit. Many thanks!
Thanks Will. Patch committed to master. Closing as FIXED.