Add experimental option to only process IAccessible events for focus ancestry, etc.

[LeonarddeR]

Original pr by @jcsteh

Link to issue number:

Replaces #11437 Fixes #11077.

Summary of the issue:

Currently, NVDA listens for all win events. It drops events for background windows and some other cases, but there can be a lot of events for objects in the foreground window that aren't interesting to the user. As well as being a performance concern, this can cause events for the focus to be dropped from the limiter due to a flood of events from other objects, resulting in problems such as #10484.

Description of how this pull request fixes the issue:

In this PR, most win events are dropped before they're even added to the limiter unless they're for the focus, a focus ancestor or the desktop object. Certain events have to be allowed regardless of object; e.g. valueChange for progress bars. Show events have to be allowed for certain window classes; e.g. tooltips.

Testing strategy:

• [ ] Get a proper test case

Known issues with pull request:

• For now, this is an option in advanced settings disabled by default, since there is a risk of unforeseen regressions. It also breaks eventHandler.requestEvent, though this is also the case for selective UIA event registration. Nevertheless, it could be useful to have advanced users test this in various situations to see if it resolves problems.
• If we decide to pursue this beyond an experiment, we'll need to re-think eventHandler.requestEvent.
• It duplicates the window classes for which we process show events from eventHandler.shouldAcceptEvent. Again, if we pursue this beyond an experiment, we'll need to re-think eventHandler.shouldAcceptEvent.

Change log entries:

New features

Code Review Checklist:

• [x] Pull Request description is up to date.
• [x] Unit tests.
• [x] System (end to end) tests.
• [ ] Manual testing.
• [x] User Documentation.
• [ ] Change log entry.
• [x] Context sensitive help for GUI changes.
• [x] UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers

[LeonarddeR]

I had to close #10484 because the codepen was lost and another example did not reproduce. Therefore I think we need another test case for the impact of this.

[LeonarddeR]

@cary-rowen and @lijianwei2019, given you seemed interested in the progress of this pr, could you elaborate on how it benefits you?

[codeofdusk]

Given that NVDA is slow to process events (#11002), anything that can be done to filter them seems like it would have at least some performance benefit.

[LeonarddeR]

Note that this pr doesn't touch UIA at all. It's not that I don't see that there's likely a benefit for this pr, I only want to have a firm test case to prove a point.

[cary-rowen]

HI leonardder,

NVDA's fluency headquarters is satisfactory, which is manifested in some programs with more object levels. I very much hope that NVDA can improve in these areas.

[lijianwei2019]

HI leonardder,

In programs with more objects and more levels of complexity. Users are not ideal for a smooth experience.

[codeofdusk]

@leonardder What is the current status of this PR? Anything blocking this being merged (as a feature disabled by default)?

[LeonarddeR]

As long as we don't have a good test case to prove that this pr actually improves things, I'm reluctant to bring this further. It is much more important to invest in UIA performance.

[lijianwei2019]

@jcsteh Do you still have good test cases?

[jcsteh]

The scenario I described in #11077 involves focusing the message list in Slack; i.e. pressing up arrow from the compose text box to move into the message list. Firefox has become significantly faster since then, but on my system, it still takes around 140 ms from the time i press up arrow to the time NVDA speaks something. I haven't tested this PR yet, but it'd be interesting to know whether that time is still improved.

[LeonarddeR]

I'm goin to close this as abandoned. Whoever wants to pick this up, feel free to take it.