wxAssertion error when closing braille or speech settings panels.

[zstanecic]

Steps to reproduce:

1. Open, for example the NVDA voice settings,
2. try to change something or nothing, it is based on your preferences and taste,
3. press enter to save, and/or escape to destroy your changes

Actual behavior:

NVDA plays an error sound and produces the following exception, see log

ERROR - unhandled exception (09:33:35.263) - MainThread (7112):
wx._core.wxAssertionError: C++ assertion ""GetWindow() != 0"" failed at ..\..\src\common\wincmn.cpp(3919) in wxWindowAccessible::GetDescription(): 

The above exception was the direct cause of the following exception:
SystemError: <class 'wx._core.WindowDestroyEvent'> returned a result with an error set

Expected behavior:

NVDA should close this dialog without these types of exceptions and errors

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

NVDA version alpha-22123,8665526b

Windows version:

Using Windows version 10.0.19042 workstation

Name and version of other software in use when reproducing the issue:

Not applicable

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.

Not applicable

If add-ons are disabled, is your problem still occurring?

Not applicable, NVDA core level

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Not applicable

[zstanecic]

To give you more hints: this issue started to appear after introducing commit which included fetching accessible labels from wx directly.

[XLTechie]

I can replicate this for the following settings categories, but not for the others: Speech Braille Voice

[seanbudd]

Sounds related to #12219 / #12215

[lukaszgo1]

Is this still reproducible? For me it isn't but I was never able to reproduce this on my system.

[zstanecic]

This is reproducible with the error log ERROR - unhandled exception (11:33:41.769) - MainThread (8416): wx._core.wxAssertionError: C++ assertion ""GetWindow() != 0"" failed at ..\..\src\common\wincmn.cpp(3919) in wxWindowAccessible::GetDescription(): The above exception was the direct cause of the following exception: SystemError: <class 'wx._core.WindowDestroyEvent'> returned a result with an error set

[feerrenrut]

I can reproduce this, and I have been investigating.

Here is what I have found

• Only the braille and speech settings panels have the failure.
• These both share a common layout. A group (StaticBox), containing a label (StaticText), ExpandoTextCtrl, and Button.
• In Fix right-to-left layout direction issues #12181, we were advised to make the StaticBox the parent of any controls in the StaticBoxSizer
• No reproduce if making the SettingsPanel the parent of the ExpandoTextCtrl
• No reproduce if replacing the ExpandoTextCtrl with TextCtrl. This affects the appearance negatively.
• No reproduce if explicitly calling destroy on the ExpandoTextCtrl before the rest of the panel is exited.

I have tried to create a minimal test app, however could reproduce the issue.

When attaching VisualStudio Debugger to NVDA, the issue is no longer reproducible.

[feerrenrut]

There doesn't seem to have been many recent changes in wxAccessible in the wxWidgets repo. I suspect that we only now get this assertion because wxPython has enabled accessibility in the build of wxWidgets it includes (and we have recently updated to wxPython 4.1.1) but I have not confirmed this.

wxPython 4.1.1 seems to be using commit 493cc35 of wxWidgets

Debug symbols for Python 3.8-32bit build of wxPython 4.1.1

PR Don't create wxWindowAccessible by default #340 changes the assumptions about wxAccessible, allowing it to return NULL.

PR wxDVC accessibility tweaks #368 which enables building Accessibility features in wxWidgets by default on Windows)

[feerrenrut]

wxWidgets ticket: https://trac.wxwidgets.org/ticket/19145

[lukaszgo1]

@feerrenrut Would you be able to confirm that this issue goes away when reverting 57e02ca As this commit seems the most logical candidate to me. Perhaps using wx.Accessible would allow to create a MWE for this issue.

[XLTechie]

* No reproduce if making the SettingsPanel the parent of the ExpandoTextCtrl

What negative effects are there to doing that?

[XLTechie]

> * No reproduce if making the SettingsPanel the parent of the ExpandoTextCtrl What negative effects are there to doing that?

Oh, never mind, I think I see--it breaks RTL.

[feerrenrut]

Oh, never mind, I think I see--it breaks RTL.

Yep

Would you be able to confirm that this issue goes away when reverting 57e02ca As this commit seems the most logical candidate to me.

I had confirmed this: Here is the alpha build prior to the introduction of 57e02ca https://ci.appveyor.com/api/buildjobs/gqw4xxr46e67t1yh/artifacts/output%2Fnvda_snapshot_alpha-22114%2Ced5fca6b.exe

I also tested disabling our own accPropServer before 57e02ca was introduced. The problem is reproducible in both cases.

[feerrenrut]

A screenshot of the assertion message: