Work around frozen keyboard input while the NVDA core is frozen

[LeonarddeR]

Link to issue number:

Improves #6291

Summary of the issue:

When large chunks of text are written to a terminal window, NVDA tends to freeze entirely. The freeze tends to lock up the keyboard in such a way that a user needs to sign out of his session and sign in back again, in which case it is likely that work is lost.

Description of how this pull request fixes the issue:

This pr checks whether the core is attempting recovery way earlier than the current code does. The current code does the following:

1. Input is received
2. winInputHook executes the keyboardHandler.internal_keyDownEvent function
3. internal_keyDownEvent checks for pass through, sticky keys, etc.
4. It executes inputCore.manager.executeGesture
5. inputCore.manager.executeGesture checks whether the core is attempting recovery. If it is, it raises NoInputGestureAction
6. The finally block of internal_keyDownEvent is executed.

The code in this pull request checks the core's recovery state within the winInputHook module itself and doesn't execute keyboardHandler.internal_keyDown/UpEvent at all when the core is frozen. While it does not fix #6291, it does no longer break keyboard input entirely, allowing a user to restart NVDA by hand.

Testing performed:

Tested by @lukaszgo1

Known issues with pull request:

This approach might be a bit aggressive. We could also check the state of the watchdog in keyboardHandler, for example. However, the current code where the keyboard hook executes a massive amount of code even when the core is frozen, is certainly not something we should keep as it is.

Change log entry:

• Bug fixes
  • NVDA is now less likely to freeze in such a way that the only way to escape is signing out from your current windows session. (NVDA hangs up in terminal, when a large piece of text is loaded #6291)

[Brian1Gaff]

Does this also fix the occasional lock up when you are running a .bat file and something unexpected occurs and locks up the machine, or appears to? Its a hard one to emulate but Murphy's law suggests its usually just when you are in a hurry say with several other windows open with data in them! Brian [email protected] Sent via blueyonder. Please address personal E-mail to:- [email protected], putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "Leonard de Ruijter" <[email protected]> To: "nvaccess/nvda" <[email protected]> Cc: "Subscribed" <[email protected]> Sent: Monday, January 28, 2019 7:36 AM Subject: [nvaccess/nvda] Work around frozen keyboard input while the NVDA core is frozen (#9208)

…

### Link to issue number: Improves #6291 ### Summary of the issue: When large chunks of text are written to a terminal window, NVDA tends to freeze entirely. The freeze tends to lock up the keyboard in such a way that a user needs to sign out of his session and sign in back again, in which case it is likely that work is lost. ### Description of how this pull request fixes the issue: This pr checks whether the core is attempting recovery way earlier than the current code does. The current code does the following: 1. Input is received 2. winInputHook executes the keyboardHandler.internal_keyDownEvent function 3. internal_keyDownEvent checks for pass through, sticky keys, etc. 4. It executes inputCore.manager.executeGesture 5. inputCore.manager.executeGesture checks whether the core is attempting recovery. If it is, it raises NoInputGestureAction 6. The finally block of internal_keyDownEvent is executed. The code in this pull request checks the core's recovery state within the winInputHook module itself and doesn't execute keyboardHandler.internal_keyDown/UpEvent at all when the core is frozen. While it does not fix #6291, it does no longer break keyboard input entirely, allowing a user to restart NVDA by hand. ### Testing performed: Tested by @lukaszgo1 ### Known issues with pull request: This approach might be a bit aggressive. We could also check the state of the watchdog in keyboardHandler, for example. However, the current code where the keyboard hook executes a massive amount of code even when the core is frozen, is certainly not something we should keep as it is. ### Change log entry: * Bug fixes + NVDA is now less likely to freeze in such a way that the only way to escape is signing out from your current windows session. (#6291) You can view, comment on, or merge this pull request online at: #9208 -- Commit Summary -- * Try to work around frozen keyboard input while the NVDA core is frozen -- File Changes -- M source/winInputHook.py (5) -- Patch Links -- https://github.com/nvaccess/nvda/pull/9208.patch https://github.com/nvaccess/nvda/pull/9208.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #9208

[LeonarddeR]

This pull request doesn't fix anything, it only makes things less bad as they are now. Your case should be at least solved in such a way that the keyboard won't be locked up.