(This may prove to be a separate bug, but it's sufficiently connected that I'll report it here for now.)

Steps to reproduce:

1. Launch the "list-item-ancestry.py" accessible event listener (which is NOT the same as the event listener attached in the opening report)

2. Perform the same steps as in the opening report.

Expected results: There would not be any dead accessibles in the list item ancestry.

Actual results (with the exception of the initial performance of step 4): There are dead accessibles in the list item ancestry.

Impact: If Orca doesn't use pyatspi's name caching, it automatically gets an updated name (i.e. the issue in the opening report is fixed). HOWEVER, it cannot ascend the accessibility tree to find out information like is the containing frame active.

Note: If you call the listener's setCacheMaskForApp with cacheName=True, you'll see an unbroken hierarchy along with the bug described in the opening report.

Sample output - NO name caching (typed: l, m, n, o)
===================================================
ancestors: [frame | ] [redundant object | ] [redundant object | ] [list box | ] [list item | l search]
ancestors: [DEAD] [DEAD] [DEAD] [list box | ] [list item | m search]
ancestors: [DEAD] [DEAD] [DEAD] [list box | ] [list item | news.google.com Google News location from history]
ancestors: [DEAD] [DEAD] [DEAD] [list box | ] [list item | o search]

Sample output - YES name caching (typed: l, m, n, o)
====================================================
ancestors: [frame | ] [redundant object | ] [redundant object | ] [list box | ] [list item | l search]
ancestors: [frame | ] [redundant object | ] [redundant object | ] [list box | ] [list item | l search]
ancestors: [frame | ] [redundant object | ] [redundant object | ] [list box | ] [list item | l search]
ancestors: [frame | ] [redundant object | ] [redundant object | ] [list box | ] [list item | l search]

Deleted: list-item-ancestry.py 1.1 KB

list-item-ancestry.py 1.1 KB View Download

Hi joanmarie.diggs@, thanks for the report. Does this seem limited to the search box in Chrome/Chromium or are there other controls we should look at?

Tentatively assigning Omnibox component and taking it - 

Notes for later:

if it's limited to omnibox we might be able to get the a11y node data here before setting it, and update+send an onchange if needed. 
https://codesearch.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_result_view.cc?l=342&rcl=73c3bd8bd89cda7ae0d8692baef93cb98792bace
However I'm not sure if other controls have this issue; if so, we'd probably want to look at a higher level.

Marking as untriaged so it'll get picked up in the normal process.

joanmarie.diggs: Can you respond to the question in Comment 2 when you get a chance?

Hi jdonnelly. I'm at TPAC, but the short answer is that I don't know if it's limited to the search box or not. Taking a look is already on my todo list.

+cc aleventhal, who was suggested was a local expert for omnibox accessibility :)

here's a tentative cl:
https://chromium-review.googlesource.com/c/chromium/src/+/1298511 

hasn't been tested yet though... I do have a linux machine and hope to tomorrow; or anyone can run with that CL if you want though since I'm headed OOO for a few days and this is currently p3.

The internal event id was pulled from another component that changes its accessible name and fires an event. It results in  We currently don't have anything in the codebase that sends an object:property-change:accessible-name directly, to my knowledge. On Windows that will get translated as EVENT_OBJECT_NAMECHANGE. On Linux, I'm not sure, apologies, but can check.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.