1633154 - Accessible event floods from certain sites make Orca extremely sluggish

Status: NEW

(Core :: Disability Access APIs, enhancement, P3)

Description

[Joanmarie Diggs]

Attachment: event-spew.py

Steps to reproduce:

1. View https://www.vesternet.com/collections/starter/products/samsung-smartthings-hub-v3
2. Launch the attached accessible-event listener in a terminal
3. Do nothing else.

Expected results: There would not be 1000s of accessibility events per second.

Actual results: There are 1000s of accessibility events per second.

Example output from the listener:

[...]
EVENT #1898: 09:26:29.999127 - [ section | ] object:text-changed:insert:system
EVENT #1899: 09:26:30.030506 - [ section | ] object:children-changed:remove:system [ unknown | £176.99]
EVENT #1900: 09:26:30.030655 - [ section | ] object:text-changed:delete:system
EVENT #1901: 09:26:30.030745 - [ list item | This item: Samsung SmartThings...] object:children-changed:remove:system [ unknown | £79.00]
EVENT #1902: 09:26:30.030827 - [ list item | This item: Samsung SmartThings...] object:text-changed:delete:system
EVENT #1903: 09:26:30.030894 - [ list item | Z-Wave Fibaro Double Switch 2 ...] object:children-changed:remove:system [ unknown | £49.00]
EVENT #1904: 09:26:30.031000 - [ list item | Z-Wave Fibaro Double Switch 2 ...] object:text-changed:delete:system
EVENT #1905: 09:26:30.031074 - [ list item | Z-Wave Fibaro Universal Dimmer...] object:children-changed:remove:system [ unknown | £49.00]
EVENT #1906: 09:26:30.031148 - [ list item | Z-Wave Fibaro Universal Dimmer...] object:text-changed:delete:system
EVENT #1907: 09:26:30.031226 - [ section | ] object:children-changed:remove:system [ unknown | £49.00]
[...]
EVENT #4041: 09:26:30.998548 - [ section | ] object:children-changed:add:system [ unknown | £55.00]
EVENT #4042: 09:26:30.998930 - [ section | ] object:text-changed:insert:system
EVENT #4043: 09:26:30.999042 - [ section | ] object:children-changed:add:system [ unknown | £115.00]
EVENT #4044: 09:26:30.999585 - [ section | ] object:text-changed:insert:system
EVENT #4045: 09:26:30.999640 - [ section | ] object:children-changed:add:system [ unknown | £76.00]
EVENT #4046: 09:26:31.000130 - [ section | ] object:text-changed:insert:system
EVENT #4047: 09:26:31.000209 - [ section | ] object:children-changed:add:system [ unknown | £91.00]
[...]

This flood doesn't appear to be just an initial thing. It just keeps spewing.

I'm sure this is a side effect of some authoring, ahem, technique. But it would be great if Gecko could detect this condition and stop flooding Orca with accessibility events. Thanks in advance!

Comment 1

[Jesse Tilson]

It sounds like you're describing an issue where Orca, a screen reader used by individuals with visual impairments, becomes sluggish when dealing with event floods from specific websites. Event floods can occur when a website generates a large number of events in a short period of time, overwhelming the system's resources and causing performance issues. https://ehsasprogramme.pk/
Here are a few steps you can consider to address this issue:
Browser Compatibility: Ensure that you are using a browser that is well-supported by Orca and is optimized for accessibility. Some browsers might handle assistive technologies better than others. It's a good idea to keep your browser and Orca updated to the latest versions.
Website Accessibility: Check if the websites in question follow best practices for web accessibility. Websites that generate excessive event floods might not be optimized for accessibility, which can lead to performance issues for assistive technologies like Orca.
Assistive Technology Settings: Explore the settings and preferences within Orca. There might be options that allow you to adjust how Orca handles events or refreshes content from websites. Adjusting these settings might help improve performance when dealing with event floods.
System Resources: Ensure that your computer has sufficient resources (CPU, RAM, etc.) to handle the demands of Orca and the websites you're visiting. Inadequate system resources can contribute to sluggishness and performance issues.
Report Issues: If you consistently encounter sluggishness on specific websites, consider reporting the issue to both the developers of Orca and the website in question. Providing feedback can help them identify and address the problem.
Temporary Workarounds: You might try using alternative browsers or different assistive technologies for specific websites that consistently cause issues. While not ideal, this can provide a temporary solution to access content without experiencing sluggishness.
Community and Support: Engage with the accessibility community to see if others have encountered similar issues and if they've found effective solutions or workarounds. Online forums, social media groups, and community websites dedicated to accessibility can be valuable resources for sharing experiences and knowledge.
Remember that assistive technologies like Orca are continuously evolving, and improvements are often made based on user feedback and the evolving landscape of web technologies. It's important to stay informed about updates, patches, and recommendations from both the Orca development team and the broader accessibility community.

Comment 2

[Joanmarie Diggs]

Hi Jesse. I'm the Orca maintainer. I'm describing the need for Gecko to implement a solution. For instance, Jamie, is there any way you could implement some sort of throttling when sites are causing event floods?

Comment 3

[James Teh [:Jamie] (away returning 3 Oct)]

Similar to bug 1758144 and friends. I'm particularly curious about your answers to bug 1758144 comment 1.

A major challenge with throttling events is which events to drop. If we drop the wrong ones, we could end up with a situation where some important cache (Orca, AT-SPI, etc.) is stale which causes other kinds of breakage. There's also the question of when you start suppressing events, how long for, etc. We can't predict what the page is going to do and these event floods might cross multiple ticks, so the best we can do here is throttle based on some pre-defined time/count constants; e.g. if e events are fired in s seconds, stop firing events for t seconds.

Comment 4

[Joanmarie Diggs]

Not sure if I answered your questions on the other bug completely or not.

As for which events to drop, children-changed might be tricky (or at least require some careful thought) because AT-SPI2 uses those events to update its cached accessibility tree.

But I see no need for anyone (AT-SPI2, Orca, etc.) to be notified of all of those text changes.

Comment 5

[Joanmarie Diggs]

Oops, forgot to mention this issue I recently filed: https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/133. Maybe the logic belongs there.

Comment 6

[James Teh [:Jamie] (away returning 3 Oct)]

My other main question was: given that you've worked on Chromium a bit, are you able to shed any light on how they mitigate with floods like this, if they do at all? May as well use prior art as a starting point if there is prior art to use... :)

Comment 7

[Joanmarie Diggs]

(In reply to James Teh [:Jamie] from comment #6)

My other main question was: given that you've worked on Chromium a bit, are you able to shed any light on how they mitigate with floods like this, if they do at all? May as well use prior art as a starting point if there is prior art to use... :)

I would have to refresh my memory on that front. I'll add that to my TODO list.