Numlock state is not always honored while numpad keys are used with the shift key
Steps to reproduce:
- Turn on numlock.
- Hold down the shift key and press either the number keys, or the delete key.
Actual behavior:
Speech is interrupted, and NVDA behaves as if numlock is not turned on, e.g. navigates via the review cursor if the desktop keyboard layout is being used.
Expected behavior:
Shift and the corresponding numpad key should be passed to the focused application.
System configuration
NVDA installed/portable/running from source:
Installed.
NVDA version:
alpha-17104,6d4b1121
Windows version:
Windows 10 Home.
Name and version of other software in use when reproducing the issue:
Applications that require shift+numpad number keys, in particular Reaper.
Other questions
Does the issue still occur after restarting your PC?
Yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
Earlier snapshot versions behave similarly.
Same behavior with NVDA 2018.1 on Win7x64 in desktop keyboard layout.
Hi.
Confirmed, but also confirmed with Narrator! However, with JAWS 2019, it behaves as you would like it to behave. Therefore, I do wonder if this is a bug or feature. I'm leaning towards bug, as it is indeed expected that a number would still be entered, seeing as though the number lock is turned on.
Hi,
Five years later...
@XLTechie, is this something Numpad Nav Mode add-on can help, or need something else?
Thanks.
I suppose it could, but IMO this should be fixed in core, if it is indeed an NVDA bug.
I was unaware of this use case; I will investigate.
To my knowledge, there is no concept of "Shift+Numpad7" or similar--modifiers with numlock-on numpad keys are not meant to have any effect other than the number itself, except for the Alt key for entering extended characters..
The first question is: is Windows getting this wrong, or is NVDA?
Please note that even without NVDA (or any screen reader) running, if you enable numpad, pressing numpad4 types the digit, but pressing shift+numpad4 moves one character left (left arrow command), as if you had pressed numpad4 with numpad off. So it's not totally a bug, it's a Windows feature.
But the fact that the speech is interrupted is a bug.
Also, from NVDA's design point of view, it's surely unintended that numpad on + shift+numpad1/2/3/4/5/6/7/8/9 act as if numpad was off and shift modifier not pressed.
So in the first place, it should be clarified what should be the desired behaviour in this case.
@seanbudd you have just triaged this issue. As asked in https://github.com/nvaccess/nvda/issues/9530#issuecomment-2875525523, what is the desired behaviour then for NVDA? Should NVDA ignore Windows native behaviour in this case or just take care not to interrupt speech as if normal arrows were pressed?
apologies - I didn't realise there were pending questions. let me get back to you
We think NVDA should just take care not interrupt speech