An alternative of pr #11477
This time, send the VK_NONE from the main thread, if the script does not send the gesture. This completely avoids deliberate reentrancy in the keyboard hook, and also avoids a time.sleep and the call to wx.yield in the winInputHook thread (which causes a wx assertion). Users report that no only does this fix the issue but this also massively speeds up holding down of control+shift+downArrow in MS Word, no doubt due to no longer sleeping or yielding in the keyboard hook.

Link to issue number:

Fixes #9463

Summary of the issue:

background

As NVDA detects key presses in its key hook, it may block a certain key from continuing through to the Operating System if that key press is bound to a particular NvDA script. The script may or may not then choose to send the key onto the Operating system later, depending on the action it is taking.
However, certain key combinations such as control+shift, may cause an action in Windows such as changing the input language, if a main key is not also included with that key combination. E.g. control+shift by itself changes input languages, but control+shift+downArrow does not. But, if NVDA blocks control+shift+downArrow, and does not send any key, then the input language is still changed. To get around this, in its key hook, NVDA sends a special VK_NONE (0xff) when modifiers like control+shift are pressed, (whether or not NVDA scripts later send a key) to ensure that the Operating System does not change input languages.

Actual problem

To send the VK_NONE key press in its key hook, currently NVDA uses KeyboardInputGesture.send, which among other things, enters a lock and sets a global variable which flags that NVDA should ignore any injected keys at the moment (I.e. this one).
The assumption was that during the call to KeyboardInputGesture.send (or keybd_event more specifically) only the key press NVDA sent would be executed in NVDA's key hook. And because the OS would have marked it as injected, and because ignoreInjected was true, then we would exit from the reentered key hook early.
But, on some Operating systems (E.g. users in #9463 ) other key presses currently pending, may also execute in the key hook inside keybd_event. In this case though, they are not injected, and therefore the entire key hook runs, and as these key presses are most likely repeats of modifier keys that require us to send the VK_NONE, then we do this, but cause a deadlock in the winInputHook thread as our ignoreInjected lock is not reentrant. Further to this, NVDA's main thread may then actually itself call KeyboardInputGesture.send in a script (perhaps for control+shift+downArrow) which also tries to take the lock, and waits for ever as well.

See the following Python stacks:

Python stack for thread 10376 (winInputHook):
  File "threading.pyc", line 890, in _bootstrap
  File "threading.pyc", line 926, in _bootstrap_inner
  File "threading.pyc", line 870, in run
  File "winInputHook.pyc", line 79, in hookThreadFunc
  File "winInputHook.pyc", line 54, in keyboardHook
  File "keyboardHandler.pyc", line 208, in internal_keyDownEvent
  File "keyboardHandler.pyc", line 528, in send
  File "winUser.pyc", line 494, in keybd_event
  File "winInputHook.pyc", line 56, in keyboardHook
  File "winInputHook.pyc", line 54, in keyboardHook
  File "keyboardHandler.pyc", line 208, in internal_keyDownEvent
  File "keyboardHandler.pyc", line 521, in send
  File "contextlib.pyc", line 112, in __enter__
  File "keyboardHandler.pyc", line 70, in ignoreInjection 

and

Python stack for thread 11700 (MainThread):
  File "nvda.pyw", line 215, in <module>
  File "core.pyc", line 545, in main
  File "wx\core.pyc", line 2134, in MainLoop
  File "gui\__init__.pyc", line 1049, in Notify
  File "core.pyc", line 515, in run
  File "queueHandler.pyc", line 88, in pumpAll
  File "queueHandler.pyc", line 55, in flushQueue
  File "scriptHandler.pyc", line 166, in _queueScriptCallback
  File "scriptHandler.pyc", line 208, in executeScript
  File "editableText.pyc", line 385, in script_caret_changeSelection
  File "keyboardHandler.pyc", line 521, in send
  File "contextlib.pyc", line 112, in __enter__
  File "keyboardHandler.pyc", line 70, in ignoreInjection

Description of how this pull request fixes the issue:

Rather than sending the VK_NONE from the keyboard hook itself, instead send it from the main thread, by doing the following:

• inputCore.InputGesture: add an executeScript method which executes the given script passing it this gesture, by using scriptHandler.executeScript. this is implemented to allow Gesture subclasses to perform actions before / after script execution.
• scriptHandler._queueScriptCallback: call Gesture.executeScript rather than executeScript directly.
• keyboardHandler.KeyboardInputGesture: track the number of times this Gesture instance is sent as input onto the Operating System (I.e. how many times Gesture.send is called). this is recorded on a sendCount instance variable. This is useful to see if a script has actually sent its gesture on or not.
• keyboardHandler.KeyboardInputGesture: implement executeScript, which after executing the script normally, checks to see if the gesture was never actually sent, and that the gesture's modifiers could possibly perform an OS action (such as an input language change) and if so then sends key down and key up for the special VK_NONE key. This code was moved from internal_keyDownEvent. Having this code execute from the main thread as opposed to the keyboard hook, stops a deadlock with the ignoreInjection hook and stops deliberate reentrancy of the keyboard hook.

Testing performed:

Ran the steps in #9463 locally, confirming the freeze / exit cannot be reproduced. Also provided a try build on that issue and had multiple users confirm the freeze / exit is gone for them.

Known issues with pull request:

None.

Change log entry:

Bug fixes:

• NVDA will no longer freeze or exit when holding down control+shift+downArrow in Microsoft Word. (NVDA exits automatically in MS Word when working with this document #9463)