Date   

Re: Possible NVDA Bug - click fired at wrong element in firefox

Bill Dengler
 

Which version of NVDA are you using?

Bill

On Jul 18, 2020, at 21:20, Rich Caloggero <richcaloggero@...> wrote:

Tried again with fast browsing set to off, and I get same behavior as initially described.

The reason I thought that turning fast browsing off did nothing is because it seems that if your virtual cursor is on the first character of an item (for example the link hello), then nothing happens. However, if you move to the "e" and press enter, then the link gets a click.

I guess this is definately "slow browse mode"! <smile>

-- Rich


-- Rich

On 7/18/2020 7:35 PM, Bill Dengler wrote:
Is this fixed when disabling fast browse mode (NVDA+8)? When fast browse is
off NVDA will say "automatically set focus to focusable elements on".
Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Rich
Caloggero
Sent: Saturday, 18 July 2020 16:39
To: nvda-devel@groups.io
Subject: [nvda-devel] Possible NVDA Bug - click fired at wrong element in
firefox
Briefly, when an element has focus, either a natively focused element, or
one made focusable via tabindex, NVDA fires a click at it when enter is
pressed. This happens even if a keydown handler is attached.
When focused on a natively focusable element like button and enter is
pressed, focus goes to the button.
When focused on a div with tabindex="0", the click is not fired at the div
with focus; instead it is sent to the first node encountered by a depth
first search of the tree, rooted at the focused item.
See more explanation and a test at this URL:
https://github.com/RichCaloggero/test/blob/master/click-test.md
Has anyone else encountered this behavior?
-- Rich


Re: Possible NVDA Bug - click fired at wrong element in firefox

Rich Caloggero
 

Tried again with fast browsing set to off, and I get same behavior as initially described.

The reason I thought that turning fast browsing off did nothing is because it seems that if your virtual cursor is on the first character of an item (for example the link hello), then nothing happens. However, if you move to the "e" and press enter, then the link gets a click.

I guess this is definately "slow browse mode"! <smile>

-- Rich


-- Rich

On 7/18/2020 7:35 PM, Bill Dengler wrote:
Is this fixed when disabling fast browse mode (NVDA+8)? When fast browse is
off NVDA will say "automatically set focus to focusable elements on".
Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Rich
Caloggero
Sent: Saturday, 18 July 2020 16:39
To: nvda-devel@groups.io
Subject: [nvda-devel] Possible NVDA Bug - click fired at wrong element in
firefox
Briefly, when an element has focus, either a natively focused element, or
one made focusable via tabindex, NVDA fires a click at it when enter is
pressed. This happens even if a keydown handler is attached.
When focused on a natively focusable element like button and enter is
pressed, focus goes to the button.
When focused on a div with tabindex="0", the click is not fired at the div
with focus; instead it is sent to the first node encountered by a depth
first search of the tree, rooted at the focused item.
See more explanation and a test at this URL:
https://github.com/RichCaloggero/test/blob/master/click-test.md
Has anyone else encountered this behavior?
-- Rich


Re: Possible NVDA Bug - click fired at wrong element in firefox

Rich Caloggero
 

When fast browse is enabled, I get the behavior I described.

When fast browse is off, pressing enter on focusable items, even those with native keyboard handling, seems to do nothing!

-- Rich


-- Rich

On 7/18/2020 7:35 PM, Bill Dengler wrote:
Is this fixed when disabling fast browse mode (NVDA+8)? When fast browse is
off NVDA will say "automatically set focus to focusable elements on".
Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Rich
Caloggero
Sent: Saturday, 18 July 2020 16:39
To: nvda-devel@groups.io
Subject: [nvda-devel] Possible NVDA Bug - click fired at wrong element in
firefox
Briefly, when an element has focus, either a natively focused element, or
one made focusable via tabindex, NVDA fires a click at it when enter is
pressed. This happens even if a keydown handler is attached.
When focused on a natively focusable element like button and enter is
pressed, focus goes to the button.
When focused on a div with tabindex="0", the click is not fired at the div
with focus; instead it is sent to the first node encountered by a depth
first search of the tree, rooted at the focused item.
See more explanation and a test at this URL:
https://github.com/RichCaloggero/test/blob/master/click-test.md
Has anyone else encountered this behavior?
-- Rich


Re: Possible NVDA Bug - click fired at wrong element in firefox

Bill Dengler
 

Is this fixed when disabling fast browse mode (NVDA+8)? When fast browse is
off NVDA will say "automatically set focus to focusable elements on".

Thanks,
Bill

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Rich
Caloggero
Sent: Saturday, 18 July 2020 16:39
To: nvda-devel@groups.io
Subject: [nvda-devel] Possible NVDA Bug - click fired at wrong element in
firefox

Briefly, when an element has focus, either a natively focused element, or
one made focusable via tabindex, NVDA fires a click at it when enter is
pressed. This happens even if a keydown handler is attached.

When focused on a natively focusable element like button and enter is
pressed, focus goes to the button.

When focused on a div with tabindex="0", the click is not fired at the div
with focus; instead it is sent to the first node encountered by a depth
first search of the tree, rooted at the focused item.

See more explanation and a test at this URL:

https://github.com/RichCaloggero/test/blob/master/click-test.md

Has anyone else encountered this behavior?

-- Rich


Possible NVDA Bug - click fired at wrong element in firefox

Rich Caloggero
 

Briefly, when an element has focus, either a natively focused element, or one made focusable via tabindex, NVDA fires a click at it when enter is pressed. This happens even if a keydown handler is attached.

When focused on a natively focusable element like button and enter is pressed, focus goes to the button.

When focused on a div with tabindex="0", the click is not fired at the div with focus; instead it is sent to the first node encountered by a depth first search of the tree, rooted at the focused item.

See more explanation and a test at this URL:

https://github.com/RichCaloggero/test/blob/master/click-test.md

Has anyone else encountered this behavior?

-- Rich


NVDA does not read list items in SpeedCommander, if the view is set to thumbnails or icons

 

Hello NVDA developers,

I have a problem with NVDA not reading names of files and folders in the SpeedCommander file manager, if its list view is set to thumbnails or icons. I've wrote the report below to the SpeedCommander developer, but he said the following:

I can't say why NVDA won't read the names. SpeedCommander uses the normal Windows list view with the built-in accessibility support. Maybe the guys from NVDA can give you more information here?

I'm attaching the NVDA 2020.1 log with logging level set to "Debug". While NVDA was logging, I went to the SpeedCommander file manager, switched its list view between a few of the view modes, including thumbnails and icons and reproduced the issue. Is there enough useful information in the log to help diagnose the issue?

And here is the report that I sent to the SpeedCommander developer:

I have a few folders with videos and/or images, for which I've configured SpeedCommander to show them in thumbnails view. And when navigating in those folders, I've noticed that the NVDA screen reader fails to read the names of the list (folder) items, no matter if they are folders or files. This applies for each folder which is configured to show its content as thumbnails or icons. I don't remember this issue being present in SpeedCommander 18, though I can't test at the moment, since I've uninstalled it yesterday before installing the new version. Strangely enough, the other two screen readers that I have - Narrator and JAWS do not exhibit this behavior/bug - only NVDA does.

Steps to reproduce the bug:

  1. Install SpeedCommander 19.
  2. Launch SpeedCommander 19 and configure it to show the folder view as thumbnails or icons.
  3. Launch the NVDA screen reader.
  4. While the focus is in the folder list with the thumbnails/icons view, use the arrow keys to move the focus between the items.

Expected results: NVDA should read the names of the folders and files in the view.

Actual results: NVDA does not read the currently focused item.

Test environment:

  • Operating system: Windows 10 Pro version 2004 (build 19041.388), 64-bit, in Bulgarian with all locale settings set to "Bulgarian".
  • SpeeedCommander version: 19.00.9800, 64-bit, in english.
  • NVDA version: 2020.1, in bulgarian (though the NVDA locale does not matter in this case - I've tested it).

I remain at your disposal if you need more information and/or assistance in solving this issue.

Thanks in advance!

______
Best wishes,
Kostadin Kolev


NVDA Add-on development Guide: 2020.2 edition in progress

 

Hello all,

NVDA Add-on Development Guide 2020.2 edition is in progress, hopefully to be published next week. As we are beyond Python 3 transition, the guide will see some important changes as a result. The current dev guide can be found at:

https://github.com/nvdaaddons/DevGuide/wiki/NVDA-Add-on-Development-Guide

 

Changes:

  • Strictly Python 3 code.
  • Link to download Python 2 will be removed with a note that the community recommends using Python 3 in production environments.
  • Python 3.7.8 download link will be added, replacing 3.7.7.
  • SCons version will be 3.1.2 or later.
  • Git version will be 2.25.0 or later.
  • Script decorator example will be added.
  • Changes as requested by the community.

 

Cheers,

Joseph


Re: comtypes/gen empty

derek riemer
 

never mind. I deleted a file in source/comTypes on accident. I just did a git checkout source/comTypes/

On Fri, Jul 17, 2020 at 1:53 AM Derek Riemer <driemer.riemer@...> wrote:
I'm getting the following error, and comtypes/gen/ is empty besides the stub file. DOes anyone have a clue how to continue?
CRITICAL - external:__main__ (01:52:02.816) - MainThread (5800):
core failure
Traceback (most recent call last):
  File "C:/Users/driem/nvda\source\nvda.pyw", line 215, in <module>
    core.main()
  File "core.py", line 256, in main
    import appModuleHandler
  File "appModuleHandler.py", line 27, in <module>
    import NVDAHelper
  File "NVDAHelper.py", line 19, in <module>
    import eventHandler
  File "eventHandler.py", line 11, in <module>
    import api
  File "api.py", line 19, in <module>
    import NVDAObjects.IAccessible
  File "NVDAObjects\IAccessible\__init__.py", line 22, in <module>
    import IAccessibleHandler
  File "IAccessibleHandler\__init__.py", line 26, in <module>
    import UIAHandler
  File "UIAHandler.py", line 11, in <module>
    from _UIAHandler import *  # noqa: F403
  File "_UIAHandler.py", line 29, in <module>
    from comtypes.gen import UIAutomationClient as UIA
ImportError: cannot import name 'UIAutomationClient' from 'comtypes.gen' (C:\Users\driem\nvda\include\comtypes\comtypes\gen\__init__.py)


--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com






--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com





comtypes/gen empty

derek riemer
 

I'm getting the following error, and comtypes/gen/ is empty besides the stub file. DOes anyone have a clue how to continue?
CRITICAL - external:__main__ (01:52:02.816) - MainThread (5800):
core failure
Traceback (most recent call last):
  File "C:/Users/driem/nvda\source\nvda.pyw", line 215, in <module>
    core.main()
  File "core.py", line 256, in main
    import appModuleHandler
  File "appModuleHandler.py", line 27, in <module>
    import NVDAHelper
  File "NVDAHelper.py", line 19, in <module>
    import eventHandler
  File "eventHandler.py", line 11, in <module>
    import api
  File "api.py", line 19, in <module>
    import NVDAObjects.IAccessible
  File "NVDAObjects\IAccessible\__init__.py", line 22, in <module>
    import IAccessibleHandler
  File "IAccessibleHandler\__init__.py", line 26, in <module>
    import UIAHandler
  File "UIAHandler.py", line 11, in <module>
    from _UIAHandler import *  # noqa: F403
  File "_UIAHandler.py", line 29, in <module>
    from comtypes.gen import UIAutomationClient as UIA
ImportError: cannot import name 'UIAutomationClient' from 'comtypes.gen' (C:\Users\driem\nvda\include\comtypes\comtypes\gen\__init__.py)


--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com





Re: How to check if current navigator object is an image?

Noelia Ruiz
 

Hi Shubham, imo there is not a definitive way. In fact, the OCR
feature in NVDA can be run regardless of the object role and sometimes
it says that there is not visible content. I think that, if we can be
sure that something is not an image, it may prevent or report it in
certain cases.
Not sure. Looking forward to see more about your work.
Thanks

2020-07-16 9:21 GMT+02:00, Shubham Jain <@ShubhamJain>:

My code is as follows:
import api
nav = api.getNavigatorObject()

I then check if nav.role is equal to ROLE_GRAPHIC (from controlTypes.py )
to determine if it is an image or not. But in many instances, images do not
have a role of graphic. For example, images opened in the default photo
viewer app of Windows 10 have the role ROLE_STATICTEXT while some images in
the browser have the role ROLE_LINK or ROLE_DOCUMENT.

Is there a definitive way to determine is a navigator object is an image?




Re: Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hi,

Perhaps. What can help with that effort is source code comments and separating patches into separate modules so that when it comes time to send pull requests to NVDA, just the needed parts can be picked and submitted. Another thing I’m going to do (provided that Andre agrees) is convert scripts into script decorators, along with letting the add-on take advantage of more modern NVDA changes.
Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Thursday, July 16, 2020 1:20 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hey Joseph,

 

Though I don't have time too look into this myself, I really dig this idea and am looking forward for it to progress.

One thing that could also be taken into account while refactoring is monkey patching. If we have an overview of what functionality in the add-on requires monkeypatching currently, we can propose better ways in NVDA core to handle these cases, such as with extension points.

 

Regards,

Leonard

 

On 16/07/2020 09:50, Joseph Lee wrote:

Hello all, especially to Braille Extender fans,

 

People watching Braille Extender GitHub repo (https://github.com/andre9642/brailleextender) may have noticed various issues about code maintenance and such, with the ultimate goal being bringing requested features from this add-on to NVDA itself. In preparation for that, I’m studying and taking notes on cleaning up the add-on source code with the following goals in mind:

 

  • Properly port Braille Extender to Python 3
  • Make source code conform better with Python idioms, best practices, and expectations
  • Run general lint over the entire source code to make them more readable and compliant with expectations from NVDA source code
  • Perform under the hood optimizations (this involves bytecode disassembly)

 

Knowing that I and Andre cannot do this alone, I would like to request your assistance in identifying much needed rewrites throughout Braille Extender add-on. At the moment I’m working on Python 3 porting, Flake8-based lint, and under the hood optimizations. See the above link for source code URL, and if you can, please submit new issues on the repo and send in pull requests to Andre. And please don’t forget that whenever you look at this add-on, be mindful that some of its features may end up becoming part of NVDA in the future.

 

Thanks.

Cheers,

Joseph


Re: Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hey Joseph,


Though I don't have time too look into this myself, I really dig this idea and am looking forward for it to progress.

One thing that could also be taken into account while refactoring is monkey patching. If we have an overview of what functionality in the add-on requires monkeypatching currently, we can propose better ways in NVDA core to handle these cases, such as with extension points.


Regards,

Leonard


On 16/07/2020 09:50, Joseph Lee wrote:

Hello all, especially to Braille Extender fans,

 

People watching Braille Extender GitHub repo (https://github.com/andre9642/brailleextender) may have noticed various issues about code maintenance and such, with the ultimate goal being bringing requested features from this add-on to NVDA itself. In preparation for that, I’m studying and taking notes on cleaning up the add-on source code with the following goals in mind:

 

  • Properly port Braille Extender to Python 3
  • Make source code conform better with Python idioms, best practices, and expectations
  • Run general lint over the entire source code to make them more readable and compliant with expectations from NVDA source code
  • Perform under the hood optimizations (this involves bytecode disassembly)

 

Knowing that I and Andre cannot do this alone, I would like to request your assistance in identifying much needed rewrites throughout Braille Extender add-on. At the moment I’m working on Python 3 porting, Flake8-based lint, and under the hood optimizations. See the above link for source code URL, and if you can, please submit new issues on the repo and send in pull requests to Andre. And please don’t forget that whenever you look at this add-on, be mindful that some of its features may end up becoming part of NVDA in the future.

 

Thanks.

Cheers,

Joseph


Braille Extender add-on: much needed code cleanup, rewrites, proper Python 3 porting and optimizations in progress

 

Hello all, especially to Braille Extender fans,

 

People watching Braille Extender GitHub repo (https://github.com/andre9642/brailleextender) may have noticed various issues about code maintenance and such, with the ultimate goal being bringing requested features from this add-on to NVDA itself. In preparation for that, I’m studying and taking notes on cleaning up the add-on source code with the following goals in mind:

 

  • Properly port Braille Extender to Python 3
  • Make source code conform better with Python idioms, best practices, and expectations
  • Run general lint over the entire source code to make them more readable and compliant with expectations from NVDA source code
  • Perform under the hood optimizations (this involves bytecode disassembly)

 

Knowing that I and Andre cannot do this alone, I would like to request your assistance in identifying much needed rewrites throughout Braille Extender add-on. At the moment I’m working on Python 3 porting, Flake8-based lint, and under the hood optimizations. See the above link for source code URL, and if you can, please submit new issues on the repo and send in pull requests to Andre. And please don’t forget that whenever you look at this add-on, be mindful that some of its features may end up becoming part of NVDA in the future.

 

Thanks.

Cheers,

Joseph


How to check if current navigator object is an image?

Shubham Jain
 

My code is as follows:
import api
nav = api.getNavigatorObject()

I then check if nav.role is equal to ROLE_GRAPHIC (from controlTypes.py)  to determine if it is an image or not. But in many instances, images do not have a role of graphic. For example, images opened in the default photo viewer app of Windows 10 have the role ROLE_STATICTEXT while some images in the browser have the role ROLE_LINK or ROLE_DOCUMENT.

Is there a definitive way to determine is a navigator object is an image?


NVDA 2020.2RC

Rui Fontes
 

Hello!


What happened to the correction to supress the Microsoft Word messages of copy, cut and so on?


Rui Fontes

NVDA portuguese team


Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hey


Looking at what you are doing it seems that knowing deterministicaly all possible impacts in all apps will be very hard.
While this is true, I think the new approach more closely resembled what other screen readers like JAWS and Narrator do.
Is there a way to port the selective UIA event registration option to a per profile configuration?

I'm afraid not. This was my initial intent, but it wasn't possible as noted in this earlier thread.


On 07/07/2020 03:53, Joseph Lee wrote:
Hi,
Re-initializing UIA handler thread is a performance nightmare - causes NVDA to freeze until the thread comes to life.
There are two possible routes I've investigated, both involving event handlers and a pointer to UIA element for the object in question (obj.UIAElement):
1. Re-register local event handler group for the specific element by calling UIAHandler.handler.removeEventHandlerGroup then UIAHandler.handler.addEventHandlerGroup in that order for each UIA event the object needs to deal with. Code that needs to run on NVDA 2020.2 beta and earlier must check existence of "addEventHandlerGroup" in UIA handler thread and see if selective event registration is enabled. But that's not quite flexible.
2. Instruct UIA handler thread to listen to events for the specific element: this can be done by calling UIAHandler.handler.addLocalEventHandlerGroupToElement. The good news is that unlike option 1, you don't have to specify exactly which event handler group you want to register the element with. The big downside is that if an application generates new UIA elements (say, when a list opens each time something happens), calling UIAHandler.handler.removeLocalEventHandlerGroupToElement will NOT remove elements in the internal elements set - you must clean them up by cycling through the set of locally registered elements by criteria such as process ID, automation ID, UIA class name and such, followed by removing found elements (process ID is more reliable than automation ID because multiple processes may come with elements proclaiming the same automation ID; this isn't recommended but sometimes this is seen with some Windows 10 apps, even those from Microsoft).
For folks who may not know what Leonard, Bill, and I are talking about:
An event handler group is a collection of events for a UIA element. When a UI Automation client such as NVDA starts, it informs UIAutomationCore.dll that the client needs to listen to events coming from any UIA element, ranging from the currently focused element to the whole UIA tree (everything). In the past, a UIA client would register event handlers one at a time. Starting with Windows 10 Version 1809 (October 2018 Update) and Server 2019, a more convenient way to organize events called "event handler group" was introduced (part of IUIAutomation6 interface). The biggest benefit is that rather than registering one event handler at a time, multiple event handlers can be registered at once, thereby improving performance (unless UIAutomationCore.dll itself is stalled).
As part of his work, Leonard added event handler group support in UIA handler (basically a COM thread). But knowing that many users are still using older Windows releases (Windows 7 Service Pack 1, Windows 8.x, Windows 10 prior to Version 1809), a fake event handler group class is introduced to simulate the actual IUIAutomation6::EventHandlerGroup behavior: trying to register multiple events at once. The code in question goes one step further by teaching NVDA to listen to events coming from system focus and its ancestors only (parent object, or the route from the desktop object to the foreground object, and in turn from the foreground window to the focused control). Although it does introduce performance benefits, it needs to be validated by further testing by testers.
The ideal testing scenarios would be:
* Traveling through UIA universes i.e. testing apps such as Visual Studio where many UIA events are fired by many things at once.
* Reading overlays i.e. modern input features, touch keyboard, among others.
* No regressions, especially for people using Windows 7 and 8.1 (not Windows 8.0 because it is end of life since January 2016); although not recommended, you should test the code on unsupported Windows 10 releases (1507, 1511, 1607, 1703) if needed.

The way I test this code is (note: you don't have to follow exactly what I'm doing):
1. Enable selective UIA event registration. YOU MUST SAVE SETTINGS AND RESTART NVDA AFTER DOING SO! Without this, UIA handler thread will not be able to enable event handler group support (this happens early in the handler thread initialization). An alternative way to do this without restarting NVDA completely is opening Python Console and typing "import UIAHandler; UIAHandler.terminate(); UIAHandler.initialize()" with each part on separate lines.
  2. Use NVDA as normal.
3. If you do encounter issues, YOU MUST RECORD WHAT NVDA IS DOING! Please do record what you are doing and how NVDA responds versus what it should do (either mentally, electronically, physically).
4. Turn off selective UIA event registration (again, RESTART NVDA!).
5. Perform the tasks that would trigger an error in step 3. Compare and record what NVDA is doing now versus what it did with selective event registration enabled.
6. If the problem is indeed caused by selective UIA registration, do let us know immediately (here or on GitHub). Please provide NVDA version, Windows version, how you are reproducing the issue (complete with app name and version, keyboard commands if applicable), and how NVDA responded (speech, braille, etc.). Although folks might be able to guess correctly, more details would help us debug faster, make NVDA more reliable, open up more test cases, and sleep better at nights (programming and debugging all night isn't fun, folks).
Hope this clarifies a lot of things.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Monday, July 6, 2020 10:59 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill
Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph
Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard
de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard

















Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

Marlon Brandão de Sousa
 

Looking at what you are doing it seems that knowing deterministicaly all possible impacts in all apps will be very hard.


Is there a way to port the selective UIA event registration option to a per profile configuration?


If it is possible then the feature can be safely distributed because it can be turned off for applications that need the full registration and turned on for others, with all the associated performance problems you described here.

On 07/07/2020 03:53, Joseph Lee wrote:
Hi,
Re-initializing UIA handler thread is a performance nightmare - causes NVDA to freeze until the thread comes to life.
There are two possible routes I've investigated, both involving event handlers and a pointer to UIA element for the object in question (obj.UIAElement):
1. Re-register local event handler group for the specific element by calling UIAHandler.handler.removeEventHandlerGroup then UIAHandler.handler.addEventHandlerGroup in that order for each UIA event the object needs to deal with. Code that needs to run on NVDA 2020.2 beta and earlier must check existence of "addEventHandlerGroup" in UIA handler thread and see if selective event registration is enabled. But that's not quite flexible.
2. Instruct UIA handler thread to listen to events for the specific element: this can be done by calling UIAHandler.handler.addLocalEventHandlerGroupToElement. The good news is that unlike option 1, you don't have to specify exactly which event handler group you want to register the element with. The big downside is that if an application generates new UIA elements (say, when a list opens each time something happens), calling UIAHandler.handler.removeLocalEventHandlerGroupToElement will NOT remove elements in the internal elements set - you must clean them up by cycling through the set of locally registered elements by criteria such as process ID, automation ID, UIA class name and such, followed by removing found elements (process ID is more reliable than automation ID because multiple processes may come with elements proclaiming the same automation ID; this isn't recommended but sometimes this is seen with some Windows 10 apps, even those from Microsoft).
For folks who may not know what Leonard, Bill, and I are talking about:
An event handler group is a collection of events for a UIA element. When a UI Automation client such as NVDA starts, it informs UIAutomationCore.dll that the client needs to listen to events coming from any UIA element, ranging from the currently focused element to the whole UIA tree (everything). In the past, a UIA client would register event handlers one at a time. Starting with Windows 10 Version 1809 (October 2018 Update) and Server 2019, a more convenient way to organize events called "event handler group" was introduced (part of IUIAutomation6 interface). The biggest benefit is that rather than registering one event handler at a time, multiple event handlers can be registered at once, thereby improving performance (unless UIAutomationCore.dll itself is stalled).
As part of his work, Leonard added event handler group support in UIA handler (basically a COM thread). But knowing that many users are still using older Windows releases (Windows 7 Service Pack 1, Windows 8.x, Windows 10 prior to Version 1809), a fake event handler group class is introduced to simulate the actual IUIAutomation6::EventHandlerGroup behavior: trying to register multiple events at once. The code in question goes one step further by teaching NVDA to listen to events coming from system focus and its ancestors only (parent object, or the route from the desktop object to the foreground object, and in turn from the foreground window to the focused control). Although it does introduce performance benefits, it needs to be validated by further testing by testers.
The ideal testing scenarios would be:
* Traveling through UIA universes i.e. testing apps such as Visual Studio where many UIA events are fired by many things at once.
* Reading overlays i.e. modern input features, touch keyboard, among others.
* No regressions, especially for people using Windows 7 and 8.1 (not Windows 8.0 because it is end of life since January 2016); although not recommended, you should test the code on unsupported Windows 10 releases (1507, 1511, 1607, 1703) if needed.

The way I test this code is (note: you don't have to follow exactly what I'm doing):
1. Enable selective UIA event registration. YOU MUST SAVE SETTINGS AND RESTART NVDA AFTER DOING SO! Without this, UIA handler thread will not be able to enable event handler group support (this happens early in the handler thread initialization). An alternative way to do this without restarting NVDA completely is opening Python Console and typing "import UIAHandler; UIAHandler.terminate(); UIAHandler.initialize()" with each part on separate lines.
2. Use NVDA as normal.
3. If you do encounter issues, YOU MUST RECORD WHAT NVDA IS DOING! Please do record what you are doing and how NVDA responds versus what it should do (either mentally, electronically, physically).
4. Turn off selective UIA event registration (again, RESTART NVDA!).
5. Perform the tasks that would trigger an error in step 3. Compare and record what NVDA is doing now versus what it did with selective event registration enabled.
6. If the problem is indeed caused by selective UIA registration, do let us know immediately (here or on GitHub). Please provide NVDA version, Windows version, how you are reproducing the issue (complete with app name and version, keyboard commands if applicable), and how NVDA responded (speech, braille, etc.). Although folks might be able to guess correctly, more details would help us debug faster, make NVDA more reliable, open up more test cases, and sleep better at nights (programming and debugging all night isn't fun, folks).
Hope this clarifies a lot of things.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Monday, July 6, 2020 10:59 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill
Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph
Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard
de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard
















Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hi,
Re-initializing UIA handler thread is a performance nightmare - causes NVDA to freeze until the thread comes to life.
There are two possible routes I've investigated, both involving event handlers and a pointer to UIA element for the object in question (obj.UIAElement):
1. Re-register local event handler group for the specific element by calling UIAHandler.handler.removeEventHandlerGroup then UIAHandler.handler.addEventHandlerGroup in that order for each UIA event the object needs to deal with. Code that needs to run on NVDA 2020.2 beta and earlier must check existence of "addEventHandlerGroup" in UIA handler thread and see if selective event registration is enabled. But that's not quite flexible.
2. Instruct UIA handler thread to listen to events for the specific element: this can be done by calling UIAHandler.handler.addLocalEventHandlerGroupToElement. The good news is that unlike option 1, you don't have to specify exactly which event handler group you want to register the element with. The big downside is that if an application generates new UIA elements (say, when a list opens each time something happens), calling UIAHandler.handler.removeLocalEventHandlerGroupToElement will NOT remove elements in the internal elements set - you must clean them up by cycling through the set of locally registered elements by criteria such as process ID, automation ID, UIA class name and such, followed by removing found elements (process ID is more reliable than automation ID because multiple processes may come with elements proclaiming the same automation ID; this isn't recommended but sometimes this is seen with some Windows 10 apps, even those from Microsoft).
For folks who may not know what Leonard, Bill, and I are talking about:
An event handler group is a collection of events for a UIA element. When a UI Automation client such as NVDA starts, it informs UIAutomationCore.dll that the client needs to listen to events coming from any UIA element, ranging from the currently focused element to the whole UIA tree (everything). In the past, a UIA client would register event handlers one at a time. Starting with Windows 10 Version 1809 (October 2018 Update) and Server 2019, a more convenient way to organize events called "event handler group" was introduced (part of IUIAutomation6 interface). The biggest benefit is that rather than registering one event handler at a time, multiple event handlers can be registered at once, thereby improving performance (unless UIAutomationCore.dll itself is stalled).
As part of his work, Leonard added event handler group support in UIA handler (basically a COM thread). But knowing that many users are still using older Windows releases (Windows 7 Service Pack 1, Windows 8.x, Windows 10 prior to Version 1809), a fake event handler group class is introduced to simulate the actual IUIAutomation6::EventHandlerGroup behavior: trying to register multiple events at once. The code in question goes one step further by teaching NVDA to listen to events coming from system focus and its ancestors only (parent object, or the route from the desktop object to the foreground object, and in turn from the foreground window to the focused control). Although it does introduce performance benefits, it needs to be validated by further testing by testers.
The ideal testing scenarios would be:
* Traveling through UIA universes i.e. testing apps such as Visual Studio where many UIA events are fired by many things at once.
* Reading overlays i.e. modern input features, touch keyboard, among others.
* No regressions, especially for people using Windows 7 and 8.1 (not Windows 8.0 because it is end of life since January 2016); although not recommended, you should test the code on unsupported Windows 10 releases (1507, 1511, 1607, 1703) if needed.

The way I test this code is (note: you don't have to follow exactly what I'm doing):
1. Enable selective UIA event registration. YOU MUST SAVE SETTINGS AND RESTART NVDA AFTER DOING SO! Without this, UIA handler thread will not be able to enable event handler group support (this happens early in the handler thread initialization). An alternative way to do this without restarting NVDA completely is opening Python Console and typing "import UIAHandler; UIAHandler.terminate(); UIAHandler.initialize()" with each part on separate lines.
2. Use NVDA as normal.
3. If you do encounter issues, YOU MUST RECORD WHAT NVDA IS DOING! Please do record what you are doing and how NVDA responds versus what it should do (either mentally, electronically, physically).
4. Turn off selective UIA event registration (again, RESTART NVDA!).
5. Perform the tasks that would trigger an error in step 3. Compare and record what NVDA is doing now versus what it did with selective event registration enabled.
6. If the problem is indeed caused by selective UIA registration, do let us know immediately (here or on GitHub). Please provide NVDA version, Windows version, how you are reproducing the issue (complete with app name and version, keyboard commands if applicable), and how NVDA responded (speech, braille, etc.). Although folks might be able to guess correctly, more details would help us debug faster, make NVDA more reliable, open up more test cases, and sleep better at nights (programming and debugging all night isn't fun, folks).
Hope this clarifies a lot of things.
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Monday, July 6, 2020 10:59 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill
Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph
Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard
de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event
registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard














Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hey,


The problem here is that it isn't very easy to switch between the global and local event registration. It requires removing all UIA event handlers and registering them again, which somehow fails, probably due to a comtypes bug. Alternatively, it could be possible to re-initialize the UIAHandler, but even of that I'm not sure, I recall that was also causing issues for me.


Regards,

Leonard

On 06/07/2020 22:20, Joseph Lee wrote:
Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard













Re: Introducing support for selective UIA event registration in NVDA Alpha snapshots

 

Hi,
Not easy, but it can be done at the event handler level (that's the route I'm taking with modern input features at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Bill Dengler
Sent: Monday, July 6, 2020 1:09 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hi,
Is it possible to disable this on a per-process level?
I've written an app module (a self-contained version of #10910) that needs to react to background windows from the app.

Thanks,
Bill
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Joseph Lee
Sent: Monday, 6 July 2020 02:20
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Hello everyone,
Folks on NVDA add-ons list may have seen the below message, but just to reiterate:
For people using Windows 10 App Essentials: you'll notice that if you do enable the option described here, you won't be able to hear emoji panel changes as you scroll through emoji categories. I'm testing a potential temporary fix, which will be rolling out to development snapshot users soon.
As noted by Leonard, please do file issues on GitHub should you notice regressions.
Cheers,
Joseph


-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Sunday, July 5, 2020 11:11 PM
To: nvda-devel@groups.io; program-l@...
Subject: [nvda-devel] Introducing support for selective UIA event registration in NVDA Alpha snapshots

Dear all,


As many of you may know, people using Microsoft Visual Studio or other applications mainly accessed by UIAutomation can experience some major lag while using them with NVDA. In an attempt to fix this, I've spent some hours in coming up with an approach that majorly improves performance in these applications. Thanks to great feedback from NV Access and them merging it, it can now be enabled in most recent NVDA Alpha snapshots by enabling the "Enable selective registration for UI Automation events and property changes" option in NVDA's advanced settings.


Taking Visual Studio as an example, with this option enabled, I notice major performance improvements in the following areas:

* Nuget package manager

* Loading/moving through the error list

* Options like go to base, go to implementation, go to definition. etc.

Performance improvements aren't limited to that though. To go a bit technical, rather than requesting for all UIA events and processing/discarding them in NVDA's process, we're now mostly only requesting events for objects of interest. This means that many events fired on other controls than the focused control aren't simply discarded by NVDA, but rather not even seen by NVDA at all, thereby taking out the processing time needed to discard them.

As there might be some regressions introduced by this feature, it is marked advanced/experimental. As I hope it eventually will become the default, I'd really appreciate it if you could report any bugs or regressions perceived with this feature enabled on NVDA's Github.


Kind regards,

Leonard