1758144 - about:config's "show all" floods ATs with children-added accessibility events

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Attachment: table-flood.py

Steps to reproduce:

1. Load the attached accessible event listener in a terminal
2. Launch Firefox and load about:config
3. Click "Show All"

Expected results: No event flood

Actual results: Over 4500 children-changed add events get fired by an accessible object with role table, adding a table row.

Impact: Orca grinds to a halt.

I've committed a change just now to Orca master to try to make things suck a bit less, but stopping this event flood would be awesome.

Comment 1

[James Teh [:Jamie]]

See also bug 1251992.

I'm not really sure how to deal with these children-changed event flooding situations for ATK. As I understand it, the children-changed event is supposed to include the index of the child which changed. I just looked at the docs and it can be set to -1 if necessary, but I'm guessing you don't want that all the time.

Gecko has a reorder event which only fires once per tick on the parent whose children changed. That sounds more like what you want. However, you would never get the index of the child that changed in that case because the reorder event doesn't have that information: there could be more than one child which changed.

In bug 1251992 comment 15, you proposed some changes to how we fire these, but I'm unclear on how you want to handle this child index situation.

I know you've done a lot of work to improve Chromium for ATK. Can you tell me how Chromium handles situations like this and what it does about child index?

As a side note, looking at the ATK code, I'm pretty sure we're firing with the wrong child index anyway. It looks like we're getting the child index of the parent, not the child that changed. That change was made as part of a refactor in 2016. I might be reading the code wrong, but I don't think so. Does Orca pay attention to the child index in this event at all? If it doesn't, that might explain why no one has noticed this.

Comment 2

[Morgan Reschenberg [:morgan]]

Triaging as S2 for performance reasons, please reassign if that's incorrect :)

Comment 3

[James Teh [:Jamie]]

While this is pretty nasty when it occurs, pressing Show all in about:config is a pretty rare use case and there don't seem to have been equivalent reports of problems like this in other real world use cases. Thus, I'm downgrading to s3.

Comment 4

[Joanmarie Diggs]

Orca doesn't use the index of that event in its decision-making. Mind you, I've noticed the index in Orca's debugging output.

Related aside to the bigger issue: Recently I filed https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/133. Maybe the logic belongs there.