Java Access Bridge calls ideally should not be done on NVDA main thread

[thgcode]

Is your feature request related to a problem? Please describe.

Yes. Some time ago I posted this snippet of code, that can freeze NVDA because Java Access Bridge takes some time to return the accessible context to NVDA. If the sleep interval is increased, NVDA can freeze as much as the time that the Java Access Bridge takes to return:

import javax.accessibility.AccessibleContext;
import javax.swing.*;

public class Main {
    public static void main(String[] args) throws Exception {
        var frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        JButton start = new JButton("Start");
        frame.add(start);

        JButton quit = new JButton("Quit") {
            @Override
            public AccessibleContext getAccessibleContext() {
                return new JButton.AccessibleJButton() {
                    @Override
                    public String getAccessibleName() {
                        try {
                            Thread.sleep(2000);
                        } catch (InterruptedException e) {
                            throw new RuntimeException(e);
                        }

                        return super.getAccessibleName();
                    }
                };
            }
        };

        frame.add(quit);

        frame.setVisible(true);
    }
}

Describe the solution you'd like

The idea would be to transfer the Java Access Bridge calls to another thread, and only post the event on the NVDA main thread when all accessible context and other needed information for the event is retrieved. This way, if Java freezes, only the thread responsible for doing the calls would be frozen.

Describe alternatives you've considered

The alternative on this program would be to remove the sleep call and unblock Java Access Bridge as soon as possible, however it depends on a program update to do it.

Additional context

NVDA calls the Java Access Bridge through the windowsAccessBridge32.dll library. This DLL uses the same thread as the program that called it (on NVDA case the main thread). If this DLL run some blocking code, NVDA would block as long as the time takes to the DLL to return.

[michaelDCurran]

This type of issue is true for pretty much all accessibility frameworks, including MSAA and UI Automation. NNVDA is primarily coded in a synchronous way from the ground up, and we have no plans right now to do a major redesign to switch to some way of making all calls asynchronous.
Even if this particular call was asynchronous, NVDA's main thread would still need to block at some point to wait for that call to complete. It is asking for the accessible name, it must block until it get it.
Certainly happy to have some philosophical discussion on future designs for screen readers, but right now this is where we are. And so far, this has not been a major issue.