Persistent 'Error checking if obj in buffer' in Firefox

[AAClause]

Since NVDA version alpha-32590,9afb6fc5 (June 27), with WebAccess enabled, the following error is continuously logged in Firefox specifically while using any keyboard-based navigation (such as Tab or arrow keys) within web page content in Firefox:

Error checking if obj in buffer
Traceback (most recent call last):
  File "virtualBuffers\gecko_ia2.pyc", line 287, in __contains__
  File "comtypes\_memberspec.pyc", line 482, in __call__
_ctypes.COMError: (-2147417842, 'The application called an interface that was marshalled for a different thread.', (None, None, None, 0, None))

Related to nvaccess/nvda#16746

Affected stable versions: 2024.2 and 2024.3.

[AAClause]

The issue appears to be linked to the following line within the WebAccess codebase:

WebAccessForNVDA/addon/globalPlugins/webAccess/webModuleHandler/__init__.py

Line 161 in 42131e4

if obj.parent and obj.parent.treeInterceptor:

This line triggers the function virtualBuffers.gecko_ia2.Gecko_ia2.__contains__. The main point of failure within this function seems to be self.rootNVDAObject.IAccessibleObject.accChild(accId), which leads to the _ctypes.COMError.

@JulienCochuyt Any idea to solve this, knowing that catching the COMError exception is not a viable option?

[AAClause]

As a temporary solution, I apply a monkey patch to the gecko_ia2.Gecko_ia2.__contains__ method by adding the following condition in the exception block (I assume this isn't the correct approach):

			if e.hresult == -2147417842:
				# The application called an interface that was marshalled for a different thread.
				return False

I'm unsure whether this requires a fix in the NVDA core or if there are errors in the WebAccess calls. However, we do not encounter these issues with Chromium-based browsers, and there was no such problem in Firefox prior to the changes in nvaccess/nvda#16746.

@jcsteh Your expertise would be greatly appreciated. :)

[jcsteh]

This indicates that you're querying buffers from a thread other than the main thread, which you should not do. The only reason this doesn't impact Chromium is that the Chromium vbuf catches all COM errors and ignores them, whereas the updated code for Firefox explicitly checks for E_INVALIDARG, which indicates that the object is not in the buffer. To put this another way, the problem does exist for Chromium; it's just being silently swallowed.