nvda
nvda copied to clipboard
nvaccess
Tracebacks logged and error sound played when using terminal or starting teamTalk on Windows 10
Filed on behalf of a user on Twitter.
Steps to reproduce:
Open Terminal and type text Or Open Teamtalk
Actual behavior:
The following traceback is shown at level error in the log:
Traceback (most recent call last):
File "comtypes\_comobject.pyc", line 154, in call_without_this
File "UIAHandler\__init__.pyc", line 568, in IUIAutomationEventHandler_HandleAutomationEvent
File "comtypes\__init__.pyc", line 278, in __getattr__
File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__
_ctypes.COMError: (-2147220991, 'An event was unable to invoke any of the subscribers', (None, None, None, 0, None))
Expected behavior:
No errors.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
2022.4beta2
Windows version:
Windows 10 19044
Name and version of other software in use when reproducing the issue:
TeamTalk 5
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
Did not occur in 2022.3.
If add-ons are disabled, is your problem still occurring?
Yes.
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes.
Line 568 of UIAHandler/__init__.py is where className tries to be fetched to see if a textChanged event should be handled.
Most likely introduced by pr #14067.
My first thought is that CachedClassName could be used instead of CurrentClassName. But Clearly this is flaky on windows 10, so perhaps that whole iff check should be moved into its own function, and then called within a try except COMError, logging debugWarning / returning on failure.
I imagine that TeamTalk was a fluke just because it used UIA, though it did seem to happen repeatedly if I closed and relaunched the app that session. If I restart NVDA, it doesn't happen again. The terminal thing was with Windows Terminal, originally noticed when calling exit on a terminal which had heretofore run the entire build job of Media Autobuild Suite, though the same thing appeared to happen after some particularly verbose output from WSL. Calling exit not only caused that particular tab to close but the window to close as well, and the flood lasted for 3 times as long, about 12 seconds that time. I'm unsure if it's related to sometimes typing text in the Windows terminal immediately causing an error tone, which appears to be some kind of process error related to diff-match-patch, but I suspect not. Windows terminal support in Windows 10 is flakey at best in so many ways but I don't think that's related to this issue, as that's more due to lack of proper behavior whereas this is outright dumps of comtypes going mad.
I should also note that the TeamTalk I was using was TeamTalk v 5.11 QT, not the classic client. The full error log can be found here, which includes some kind of exception handling chain going wrong and an implementation error of some sort. But I say flood because this error spams the hell out of the log, causing 4+ seconds of continually interrupted error tones and in this case over 66 kilobytes of output. This just seems to pop up randomly, perhaps after NVDA's been running for some time, and the circumstances to invoke it seem to be completely random and unpredictable, making reproduction quite difficult. Have not tried COM registration tool and have restarted after upgrading so it isn't that odd discontinuity in implementations when the lib DLLs don't quite get changed. As far as I'm aware this did not occur in betas of 2022.3. The Windows terminal would still ignore output after some time, or sometimes not until I actually type something, but again that's unrelated to this I feel and I don't want to muddy the waters on this odd problem any further.
The number of error log messages should be reduced with PR #14317, updating the title to reflect.
I tested with NVDA 2024.1 RC1 on Windows 10 build 19045 and Terminal as well as Teamtalk. I cannot reproduce this error. I am closing as works for me. If you are still having this issue, please comment and we can reopen.