Modal dialog blocks core if CallAfter fires within wx.Yield (e.g. waiting for caret movement)

[tspivey]

STR:

1. Install testwindow.py from the zip into globalPlugins.
2. Compile test.cpp: cl test.cpp /EHsc user32.lib You might need /link /subsystem:windows - but I was ok without it.
3. Run test.exe from the run dialog.
4. When the message box appears, press enter. If NVDA doesn't freeze, try again. This also locks my keyboard.

Stack (after 10 seconds of being frozen):

File "nvda.pyw", line 190, in <module>
File "core.pyo", line 385, in main
File "wx\_core.pyo", line 8657, in MainLoop
File "wx\_core.pyo", line 7952, in MainLoop
File "core.pyo", line 356, in Notify
File "queueHandler.pyo", line 83, in pumpAll
File "queueHandler.pyo", line 50, in flushQueue
File "scriptHandler.pyo", line 145, in _queueScriptCallback
File "scriptHandler.pyo", line 187, in executeScript
File "editableText.pyo", line 113, in script_caret_newLine
File "editableText.pyo", line 62, in _hasCaretMoved
File "api.pyo", line 261, in processPendingEvents
File "wx\_core.pyo", line 8370, in Yield
File "wx\_core.pyo", line 16766, in <lambda>
File "C:\Users\tyler\AppData\Roaming\nvda\globalPlugins\testwindow.py", line 39, in test2
File "gui\__init__.pyo", line 531, in messageBox
File "wx\_misc.pyo", line 491, in MessageBox

testcrash.txt

[jcsteh]

Discussed/debugged on IRC.

Impact: If a modal GUI dialog is shown via wx.CallAfter (which is the recommended way to do this), it's possible that it might execute within a wx.Yield; e.g. waiting for the caret to move in an editable text field. This would make it block the core, which is made worse by #6797 (keys getting swallowed forever). The question is how likely this is in normal usage. I don't think it's likely in core; we don't tend to bring up dialogs except when triggered by scripts and it's not possible for wx.Yield to occur in this case. The one exception is updateCheck, which only occurs once a day, but it's not impossible we could hit this there.

@tspivey, you mentioned this was related to NVDA Remote. What's the impact for NVDA Remote users? What feature is this needed for?

I'm not sure how to fix this. Ideally, we wouldn't use wx.Yield at all, but waiting for caret movement currently depends on this to pump events. I think we also use it when sending keys. Timers aren't re-entrant, so we might be able to use this somehow?

CC @MichaelDCurran.

[ctoth]

We are creating a protocol handler for NVDARemote to be able to open nvdaremote:// links.

https://github.com/NVDARemote/NVDARemote/pull/112

This necessitates prompting the user, which I did with a gui.messageBox in a wx.CallAfter previously This was completely freezing my NVDA when I ran an nvdaremote:// link. Switching to a wx.CallLater(100, ...) worked, but is an ugly solution, and so @tspivey started tracking down the actual bug, which lead us to #6797 and here.

[jcsteh]

Thanks for the details. That raises another point: we can probably be hit by this if a user installs an add-on by opening the add-on package from the Run dialog.

[derekriemer]

@michaelDCurran was this fixed when core.callLater and friends were changed?

[jcsteh]

Nope. That fixed #6797 (keys getting swallowed forever), but not this issue.

[Adriani90]

@tspivey, @ctoth Is this still an issue in NVDA 2019.1? Unfortunately I am currently not able to compile it myself on this system, so I cannot test if this is still reproducible.

[LeonarddeR]

blocked by #8679

[feerrenrut]

Blocked by? Shouldn't this be fixed when #8679 is fixed?

[josephsl]

Hi, no wonder why NVDA appears to respond slowly under wxPython 4.1.0 if a modal dialog (such as NVDA’s own About dialog) is active. Blocks #11056 due to #8679.

[josephsl]

Hi,

Note that wxPython 4.1.0 removes deprecation warning on wx.Yield, and no, wx.YieldIfNeeded nor wx.SafeYield fixes this issue.

Based on source code tests, it appears this happens if a call is made to gui.messageBox. The following dialogs and scenarios are affected:

• NVDA's about dialog
• Prompt when about to delete a profile from configuration profiles dialog

Thanks.

[Adriani90]

@josephsl now that #11056 is fixed and NVDA uses WX python 4.1.1, is this issue resolved?

[josephsl]

Hi,

We will see if tis issue is resolved once we move to wxPython 4.2.x.

Thanks.

[Adriani90]

@tspivey, @josephsl is this now reproducible with NVDA 2024.1? NVDA is using WX 4.2.2 now.