Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State of keyboard modifiers is not tracked correctly in some cases #12609

mltony opened this issue Jul 3, 2021 · 0 comments · Fixed by #12610

State of keyboard modifiers is not tracked correctly in some cases #12609

mltony opened this issue Jul 3, 2021 · 0 comments · Fixed by #12610


Copy link

mltony commented Jul 3, 2021


A number of users have previously reported problems with NVDA incorrectly tracking the state of modifiers, e.g. NVDA thinks insert key is down, while it is really up. A couple of examples are #11744 and #11546. In many cases it's hard to define clear steps to reproduce.
I was experiencing this issue as well and found somewhat reliable way of reproducing, although it involves editing a file on a network-mounted share, so it is pretty difficult to configure.
I also think I fixed the problem, so creating this issue to be fixed with my PR.
Please note, that this is not an issue with keyboard.

Steps to reproduce:

Prerequisites: a network folder with write access, available either via windows network share (SMB) or SSHFS.

  1. Mount a network folder. Either via SMB or SSHFS-win.
    2.Create a new file on that network share and open it in Notepad++.
    3.Make any change to the file.
  2. Quickly press Control+S and then Insert+T.

Actual behavior:

At this point a number of bugs might happen. Here are a few different scenarios, of what can happen:

  1. Pressing NVDA+T doesn't announce window title. While still holding down insert key I might press T again, but still window title is not announced. Then when I alt-tab away and back, I observe multiple letters "T" were actually typed into the document. Which suggests that NVDA didn't catch me pressing insert key.
  2. Alternatively, if insert+T correctly announces the title, I may release Insert key. Then I may press some unrelated keystroke, such as Control+Z, and to my surprise this opens NVDA Python console. This suggest that NVDA didn't catch me releasing Insert key and it thinks that insert key is down and Instead of Control+Z NVDA thought I pressed Insert+Control+Z.
  3. Alternatively, when I press arrow keys, instead of their usual function, I observe that NVDA does navigate by word when I press left or right, or doesn't move anywhere when I press Up/Down. This is consistent with the hypothesis of NVDA believing that control key is down.
    Typically Either of these scenarios might reproduce with at least 10% probability, sometimes as high as 70% (percentage figures are my rough estimation).

Expected behavior:

NVDA should correctly track the state of control key, insert and other keyboard modifiers. Even when NVDA deals with a window that is not responding, e.g. frozen on network write operation.

Alternative way to reproduce

When I press Control+S followed by Alt-Tab, I also notice that sometimes Alt key gets stuck.

System configuration

NVDA installed/portable/running from source:

Tried all three.

NVDA version:

Also tried 2021.1beta1 - could only reproduce options 1 and 2, but not 3 for some reason.

Windows version:

Windows 10
Version 1803 (OS Build 17134.2145)

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

Notepad++ v7.7.1

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?


Have you tried any other versions of NVDA? If so, please report their behaviors.


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


Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?


feerrenrut added a commit that referenced this issue Jul 21, 2021
Fixes: #12609

# Summary of the issue:
NVDA wasn't correctly tracking the state of keyboard modifiers (such as Control, or Insert) in some cases,
e.g. when watchdog is recovering.

In def keyboardHook():

    if watchdog.isAttemptingRecovery or code!=HC_ACTION:
    return windll.user32.CallNextHookEx(0,code,wParam,lParam)

When watchdog.isAttemptingRecovery is True, this function returned early and didn't process any keyboard 
events, including events related to keyboard modifiers.
When a pressing a modifier while watchdog is recovering, NVDA didn't process this and became out
of sync with the keyboard state.

# Description of fix:
Move the check for isAttemptingRecovery into internal_keyDownEvent after modifier tracking has occurred but before the gesture is executed.

Co-authored-by: Reef Turner <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging a pull request may close this issue.

1 participant