1251992 - Try to reduce "unnecessary" children-changed event emission

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Attachment: pyatspi accessible-event listener

Steps to reproduce:
1. Load the attached pyatspi accessible-event listener in a terminal
2. Load/reload matrix.org

Desired results: Not 450+ object:children-changed:add:system events for images adding child images. :)

(I don't know if that's possible or not. But the act of examining these events in Orca just to rule them out as event spam still takes more time and a performance hit that is far from ideal. So if the spam could be detected and fewer events emitted, I'd be grateful.)

Comment 1

[Joanmarie Diggs]

Attachment: Output from performing steps in opening report

Comment 2

[Samuel Thibault]

Hello,

I tried to reproduce the issue with firefox 45.9.0, 52.3.0 and 55.0.3, and didn't get it with either version. I do get some events like this:

25 15:30:23 [image | ] object:children-changed:add:system [image | ]

but only a dozen of them, and only after scrolling down to the "How does it work?" part of matrix.org.

Are you still getting this precise issue?

Samuel

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Samuel Thibault from comment #2)
> Hello,
> 
> I tried to reproduce the issue with firefox 45.9.0, 52.3.0 and 55.0.3, and
> didn't get it with either version. I do get some events like this:
> 
> 25 15:30:23 [image | ] object:children-changed:add:system [image | ]
> 
> but only a dozen of them, and only after scrolling down to the "How does it
> work?" part of matrix.org.
> 
> Are you still getting this precise issue?
> 
> Samuel

Comment 4

[Joanmarie Diggs]

It looks like Matrix.org changed its site. If I had to guess, the problem may remain but a new test case would be needed. Since I'm not a JavaScript authoring type, I'll leave that to someone else. Clearing the NEEDINFO.

Comment 5

[Samuel Thibault]

Colomban mentioned on https://mail.gnome.org/archives/orca-list/2019-March/msg00144.html that the https://www.nextinpact.com/ website does seem to currently reproduce the issue.

Comment 6

[Colomban Wendling]

Attachment: pyatspi accessible-event listener for nextinpact.com

Yes, sounds very similar although it's on paragraphs here. From what I can gather now, it looks like the date/hour on the side panel "En continu" is getting updated continuously (once per second to display updates?), and results in changes being emitted.

Attached is an edited version of Joanmarie's test script to capture the issue on https://www.nextinpact.com/news/107683-relaxe-apres-avoir-injurie-tiers-par-mail.htm (or https://www.nextinpact.com/, that works as well). You'll see we get an additional 140 changes every second.

As apparently the text is replaced by the same one, maybe the events could be dropped when they form a remove/add pair that results in the same state?

Jamie, do you reproduce this on Windows, or is it really Linux-specific?

Comment 7

[Colomban Wendling]

Yes, sounds very similar although it's on paragraphs here. From what I can gather now, it looks like the date/hour on the side panel "En continu" is getting updated continuously (once per second to display updates?), and results in changes being emitted.

As apparently the text is replaced by the same one, maybe the events could be dropped when they form a remove/add pair that results in the same state.

Jamie, do you reproduce this on Windows, or is it really Linux-specific?

Comment 8

[James Teh [:Jamie]]

(In reply to Colomban Wendling from comment #6)

Jamie, do you reproduce this on Windows, or is it really Linux-specific?

I don't have a quick way of getting full data from Windows events at present. I can do this, but I'm probably not going to be able to get to it for a while. What I can say is that this doesn't seem to cause performance problems with NVDA, but there could be various reasons for that.

From what I can gather now, it looks like the date/hour on the side panel "En continu" is getting updated continuously (once per second to display updates?), and results in changes being emitted.

...

As apparently the text is replaced by the same one, maybe the events could be dropped when they form a remove/add pair that results in the same state?

I'm confused. You note that the date/time is updated, but then you note there's no change to the text. Are you able to provide more details on what events get fired on what objects?

Comment 9

[Peter Vágner]

It's about 128 events per second.
And these are only these two event types:
object:children-changed:remove:system
object:text-changed:delete:system

I don't understand french however apparently this is a news site. Next to the headings there are either relative or absolute times constantly being updated in a way that a DOM node is removed and a new one is inserted with the same content.

For text content i.e. paragraphs I imagine that is becoming tricky to filter out no matter where the filtering would take place.

However the original report where the test case is no longer available had to do with the same event types but for images being programmed to form a slideshow. Joanie has captured that because I was asking if the performance can be improved.

Looking at the script output she had captured there were about 32 object:children-changed:add:system events per second corresponding with changing images with their alt descriptions set to the word "image".

I can remember that experience the orca's responsiveness to the keypresses was about a second or even more when browsing such a site.

For sure these are both website authoring issues however it's very likelly such issues can be seen more frequently on the web and it would really be nice if there would be a way to filter out such excessive event spam.

Comment 10

[Alex ARNAUD]

Peter, many thanks for testing this, are you able to test this on windows as well ?

The impact for Hypra team would be important, if it's not reproducible on Windows, we could imagine to verify why Firefox Linux would be worse than Windows on events management.

Best regards,
Alex.

Comment 11

[Peter Vágner]

Alex,
I can load this URL in Firefox for windows with NVDA and from the users perspective I can confirm what Jamie has said that I can't see user visible impact.
I don't know how to verify this exactly. I am guessing that these events are also fired on windows however due to NVDA vs Firefox inprocess architecture it does not result in such a degraded performance there.

Comment 12

[Alex ARNAUD]

(In reply to Peter Vágner from comment #11)

Alex,
I can load this URL in Firefox for windows with NVDA and from the users
perspective I can confirm what Jamie has said that I can't see user visible
impact.
I don't know how to verify this exactly. I am guessing that these events are
also fired on windows however due to NVDA vs Firefox inprocess architecture
it does not result in such a degraded performance there.

Is there any Accerciser alternative for Windows to monitor a11y events ?

I can try on my Windows VM to check that if I've a tool for that.

Best regards,
Alex.

Comment 13

[Peter Vágner]

I have always just used NVDA's python console for dumping data and / or inspecting accessible objects. It's a few years I haven't done it so I'd need to read a bit of NVDA code to refresh my memory.
I guess Jamie is doing the same thing when testing with NVDA.
There's also the tool called Accprobe that should be usefull when diagnosing IA2 implementation.
https://accessibility.linuxfoundation.org/a11yweb/util/accprobe/

Comment 14

[Samuel Thibault]

Attachment: orca log file

For information, here is an excerpt of orca log file containing one of these series of events. It reproduces every second when the news bar of the website updates itself. There are 32 of each of object:children-changed:remove:system, object:text-changed:delete:system, object:children-changed:add:system, object:text-changed:insert:system. Orca ignores the object:children-changed:remove:system ones, but does not ignore the others, it thus has a hundred events to process, and the processing it for each is 2ms, so it ends up eating 20% cpu (and requesting information from firefox, thus making it eat cpu too).

Comment 15

[Joanmarie Diggs]

And Orca needs to pay attention to the events it is not ignoring both for text-field changes and for live-region changes. So having Orca ignore the events in question is not the answer -- at least not until we create new AT-SPI2 and ATK API specific to live regions (which I think would actually be a good idea, but that takes time).

Here's my tentative proposal:

1. Obviously text changes in editable fields MUST emit text-change notifications.
2. Anything which is an ARIA live region MUST emit text-change and/or children-change notifications.
3. Anything which doesn't fall into either of the above categories but is doing constant DOM updates, SHOULD NOT emit either. That's the old Matrix situation.
4. Any container which is (potentially) updating actual information (e.g. a news site adding and removing articles, updating timestamps, etc.) SHOULD result in one notification on the container rather than a bunch.

Some examination of sites may be called for to figure out what doesn't fall into either 1 or 2, but some ideas:

• If it's just image changes, I don't want to be notified.
• If it's a non-editable element and only a tiny bit of text is changed, I don't want to be notified.
• If a big chunk of text is added or removed, I do want to be notified.

FWIW, Orca cares about these events for the following reasons:

• Notify the user (due to text changes in editable fields, present a live region update)
• To update its various caches of objects