1874247 - Regression: Accessible focus events missing from message list when message deleted - accessible object should not be reused

Status: NEW

(Thunderbird :: Folder and Message Lists, defect)

Description

[Joanmarie Diggs]

Attachment: listener.py

Steps to reproduce:

1. Launch the attached pyatspi accessible-event listener in a terminal
2. Launch Thunderbird, place focus in the message list
3. Arrow down several times, making the current message somewhere in the middle of the list
4. Press delete

Expected results: In both steps 3 and 4, each key press would result in the listener printing the newly-focused message in the message list.

Actual results: In step 3, each key press results in the listener printing the newly-focused message in the message list. BUT, this happens rarely for step 4 (possible race condition?)

Impact: When Orca users delete a message that's in the middle of the list of messages, Orca fails to announce the newly-focused message.

Note: This is a regression. I'm afraid I don't have time at the moment to do a bisect. It also seems like the race condition I mentioned might be getting worse, but that might be a coincidence / red herring. With that disclaimer in mind.....

• (I did not test before 113 b1, sorry!)
• In 113 b1, most of the time things worked as expected, but sometimes the event was missing after a deletion.
• In 114 b1, often the event is missing after a deletion.
• Orca users reported this on the Orca mailing list as a regression in 115.
• In Daily (currently 123 a1), the event is almost always missing after a deletion.

Comment 1

[Joanmarie Diggs]

Here's what seems to be going on, based on the accessibility events Orca gets.

Old way, before the regression:

1. User deleted the selected message.
2. The parent container fired children-changed:removed and removed the deleted item. I assume that associated accessible object was being destroyed.
3. A selection-change and/or focus-change event was fired for the next item in the list that became selected as a consequence of the deletion. Orca presented the newly-selected/focused item.

New way, after the regression:

1. User deletes the selected message.
2. The accessible object associated with the selected message fires a name-changed event changing the name to match the name of the next item in the list that became selected as a consequence of the deletion. In other words, it appears to me that the accessible object is no longer being destroyed like before; it's being repurposed.
3. A selection-change event is fired on this renamed item. But Orca sees that the accessible object firing the selection change is the same accessible object that was selected prior to the deletion. In other words, the selection did not change and this event seems like an error or event spam and Orca ignores it.

While I personally think repurposing accessible objects in this fashion is not ideal, I cannot exactly call it a bug. So I just changed Orca in its main/unstable branch to present the name change. Prior to this change, Orca had been ignoring most name changes from Thunderbird due to user complaints of chattiness. But Orca no longer can do so. That's fine, and it fixes the user experience regression reported in related (duplicate?) bug 1866121.

HOWEVER, making the change I made in Orca has side effects, some of which will be easy to handle, others of which may not. As a result of this, I do not intend to backport the changes into stable versions of Orca. At least not any time soon. We don't yet know what else in Thunderbird might be firing name-changed events that Orca should not present, but now is.

Jamie: Do you have any opinions on this?

Comment 2

[James Teh [:Jamie]]

Accessible objects should not be reused in this way. It's a different list item, so it should have a different Accessible.

I'm fairly sure this is specific to Thunderbird, since I believe Thunderbird has its own message list implementation now. Thunderbird folks, please feel to correct me if this is some bug in a core XUL widget.