@michaelDCurran I'm aware of the fact that this solution is probably not ideal, though I'm sure we must somehow fix the way tree interceptors are getting in the way here.

• PR introduces Flake8 errors
• Build (for testing PR)

See test results for failed build of commit 7a677ca2cb

event_scrollingStart in the gecko_ia2 virtualBuffer will not be handled anymore, plus event_valueChange in the adobeAcrobat virtualBuffer.
I'm not worried about event_caret.
Event_focusEntered: yes this is a problem. We'd need to change api.setFocusObject and eventHandler.doPreDocumentLoadComplete to ensure the right treeInterceptor was cached on the focus ancestors which are descendants of a newly created treeInterceptor. But even if we did specifically fix this, it does significantly change the concept that treeInterceptors catch all events for all descendants. Note event_scrollingStart and event_valueChange above.
I'd like to better understand why the __contains__ on the TreeInterceptor for Chrome in VSCode is so slow.

Currently, NVDA is creating a treeInterceptor for the root of the app (The read-only document that contains everything). However, its only child is an application, thus we don't actually ever render anything.
But, Every descendant object NvDA knows about may ask if it is in this treeInterceptor. Chromium says yes (accChild on the root returns a valid object) but then we do some very costly things to check if we are inside an application in the virtualBuffer.
Unless I am really misunderstanding things here, I feel that we should reintroduce a VS Code appModule which disables the treeInterceptor on the root of the application (the top read-only document below the Desktop). As now most if not all VS code subdocuments (Release Notes etc) have correct readonly document objects, virtualBuffers will be created for each of them when needed.
If the user does however for some reason get confused or deliberately presses NVDA+space when focused in the code editor, or something that is within the application objectbut not within a subDocument, they will force a virtualBuffer for the application object, and from then on need to fiddle with NVDA+space, and they will also hit the performance problem again.
Perhaps, we should specifically also disallowing forcing a virtualBuffer on that application object as well, perhaps by making treeInterceptorClass None.

Do all Electron apps have this problem? Or will they get it if an app like Slack or Discord also introduce an application role on their respective body elements, or as in the Slack case already, somewhere further down the tree structure?

But, Every descendant object NvDA knows about may ask if it is in this treeInterceptor. Chromium says yes (accChild on the root returns a valid object) but then we do some very costly things to check if we are inside an application in the virtualBuffer.

I wonder, why don't we ask the vbuf itself whether an object is part of it? Is that less reliable?

Unless I am really misunderstanding things here, I feel that we should reintroduce a VS Code appModule which disables the treeInterceptor on the root of the application (the top read-only document below the Desktop). As now most if not all VS code subdocuments (Release Notes etc) have correct readonly document objects, virtualBuffers will be created for each of them when needed.

While I think this is a sane workaround for now, I'm afraid that we aren't fixing the actual underlying issue in that case. @MarcoZehe raised a valid point here. Though not all electron apps might have this issue, I'm pretty sure there are more apps using an application role like this. We'd have to add an exception for all of these.

If the user does however for some reason get confused or deliberately presses NVDA+space when focused in the code editor, or something that is within the application objectbut not within a subDocument, they will force a virtualBuffer for the application object, and from then on need to fiddle with NVDA+space, and they will also hit the performance problem again.

Interesting enough, the performance hit caused when there is a virtual buffer on the application object is much less prevalent.

Perhaps, we should specifically also disallowing forcing a virtualBuffer on that application object as well, perhaps by making treeInterceptorClass None.

Also feels a bit like a workaround to me, honestly.

This pr has too much regressions. It will have to be another approach. I think I'll start with reintroducing the appModule as @michaelDCurran suggested.

Filed #11657