Work around frozen keyboard input while the NVDA core is frozen#9208
Merged
Conversation
|
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
bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Leonard de Ruijter" <notifications@github.com>
To: "nvaccess/nvda" <nvda@noreply.github.com>
Cc: "Subscribed" <subscribed@noreply.github.com>
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
|
Collaborator
Author
|
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. |
michaelDCurran
approved these changes
Jan 28, 2019
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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: