GNOME Bugzilla – Bug 622864
Thunderbird 3.1: Orca temporarily becomes non-responsive due to event flooding
Last modified: 2012-08-14 20:57:38 UTC
Hi, in Thunderbir 3.1 (Version from Ubuntu Launchpad repo), in some folders orca hangs, because it is flooded by hundreds of object:property-change:accessible-name events. My impression is that it only happens in folders which belong to a mailbox which is currently is synchronized for offline use. In the other folders, orca works fine. Here's a sample event vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0,[STIMMGABEL] neues Mitglied unserer Liste Unread Martin Feuerstein 08/27/2008 06:55 PM) app.name='Shredder' name='[STIMMGABEL] neues Mitglied unserer Liste Unread Martin Feuerstein 08/27/2008 06:55 PM' role='list item' state='enabled focusable opaque selectable sensitive showing vertical visible' relations='node child of' ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ DEQUEUED EVENT object:property-change:accessible-name <---------- Thanks in advance, regards, Rudolf
I'm not trying to split hairs, honest. <smile> I can confirm this behavior. But it's not a hang per se. If you just wait and don't press any keys, perhaps go make a sandwich or something.... Orca will eventually get through the flood of name-changed events and everything will continue to work. At least until Thunderbird emits a bunch more name-changed events. <sigh> What seems to be happening is that Orca's examining of ... something ... is causing Thunderbird/Gecko emit all those name-changed events. If I just use Accerciser, only the focused list item for the message emits the event rather than all of the messages in the list doing so. I tried to solve the problem of the flood by ignoring the events, but that's not going to work because we can't ignore all such events. So we have to examine each event to determine if it should be ignored. Doing a quick, temporary de-registering for the event *might* work, but it would be a hack -- and a fragile one at that. :-( I'll dig some more to see if I can figure out exactly what's triggering it....
Created attachment 164770 [details] debug.out containing just one focus: event Here's the debug output from a single focus: event. Total number of lines: 2746. About 2500 or so are: ---------> QUEUEING EVENT object:property-change:accessible-name Bah.
Marking this for 3.0 for now. To be honest, the "fix" will I suspect be to file a bug against Gecko/Thunderbird and block this one....
The accessible name change event flooding was handled in ATK and/or AT-SPI2 a couple of release cycles ago. If you can still reproduce the problem using Orca 3.5.x please re-open.