When the command key is pressed, the modifier key is still passed to other programs.

[hwf1324]

Steps to reproduce:

In a non-NVDA GUI, such as a desktop or browser. Press a command with a modifier key.

1. Press the Ctrl key to interrupt all speech.
2. Press the NVDA key first.
3. Press the rest of the keys, e.g. Ctrl+g to open the settings dialog box.

Actual behavior:

The Ctrl key is passed to other programs

Expected behavior:

Does not pass keystrokes to other programs

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

install

NVDA version:

2024.1 beta7

Windows version:

Version 22H2 (OS build 22621.3085)

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

Need a program that reports key presses. For example, a program for keyboard sound effects or something like that.

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

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

No, but I believe it's the same.

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

Yes

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

Yes

[hwf1324]

Sometimes this doesn't happen when I press Ctrl+NVDA at the same time, but it's hard to reproduce precisely.

[CyrilleB79]

Could you describe the use case for which you consider the current behaviour to be problematic? This would help figure why this request is important.

If this request is implemented, this would mean that pressing NVDA+control+G could have a different effect than control+NVDA+G. Could this be a problem?

[hwf1324]

Actually, my use case is in the laptop keyboard scenario, moving the navigation object to the next object. I also use IME input. At this point when I press each individual gesture with Shift, it switches the input method state.

[XLTechie]

First, if shift is your big concern, you should list that in the initial description, instead of control. You can send devs off on the wrong tangent that way.

Any solution I can personally think of for this, starts with intercepting shift on key-down, and not sending it on to the application (or Windows) until key-up. That seems like it would have bad consequences for capital letters, among other things.

Further, can we even intercept it in the context of the Windows IME mode?

The only less bad thing I can think of, is to send shift again on key-up, if it was used with an NVDA command. That way, it would hopefully restore the IME state to what it was when the sequence was first pressed. I'm not sure what would happen in the some modifiers held down situation, however, such as NVDA+shift and then a few right arrows.

Whatever may be done, should likely be in an add-on.

@tspivey, @josephsl, any thoughts on this issue?

[hwf1324]

For my personal use case, I do have a problem with my description, but it's not just a problem with the Shift modifier key, the rest of the modifiers have the same problem.

My idea is that in the case of pressing the NVDA key, the other keys can be intercepted until NVDA is released. If no gesture is triggered, then the state of the key at that point is passed on to the rest of the program.

[hwf1324]

First, if shift is your big concern, you should list that in the initial description, instead of control. You can send devs off on the wrong tangent that way. Any solution I can personally think of for this, starts with intercepting shift on key-down, and not sending it on to the application (or Windows) until key-up. That seems like it would have bad consequences for capital letters, among other things. Further, can we even intercept it in the context of the Windows IME mode? The only less bad thing I can think of, is to send shift again on key-up, if it was used with an NVDA command. That way, it would hopefully restore the IME state to what it was when the sequence was first pressed. I'm not sure what would happen in the some modifiers held down situation, however, such as NVDA+shift and then a few right arrows. Whatever may be done, should likely be in an add-on. @tspivey, @josephsl, any thoughts on this issue?

Of course, for the Shift key alone, this does need to be considered.

But maybe that's a separate issue, such as "switching IME mode at the same time as pausing speech".

[josephsl]

Hi,

I think the key variable here is IME usage - some IME's assign modifiers such as Shift and Control to toggle between input modes/languages/scripts (Korean IME uses right Alt/Control to toggle between input scripts). Does this issue occur if keyboard language is set to English? I cannot reproduce this with English and Korean IME. Also, a debug log is appreciated (and I strongly advise upgrading to Windows 11 23H2 at this point).

Thanks.

[hwf1324]

One problem is if modifier keys like Ctrl or Alt are hotkeys for other programs, like IME switching.

Use English Input essentially has this problem, but English Input doesn't have a toggle so it appears to be normal.

I made up an attempt to debug the log, but there doesn't seem to be any usable information, it only reports the key combinations each time they are pressed, not the order in which they are pressed and whether they are passed on to other programs.

By the way, if there is a set of gestures like NVDA+s and NVDA+<modifier key>+s. It's easy to mistakenly trigger the NVDA+<modifier key>+s bound command on each separate simultaneous press of NVDA+<modifier key>+s.

[wmhn1872265132]

I will set the Ctrl key to switch between Chinese/English mode of Microsoft Pinyin Input Method. This problem will be encountered when using the Ctrl+numeric keyboard shortcut for NVDA. A more extensive method is to use clipboard enhancement add-on's Ctrl+numeric keyboard area shortcut key. However, since this add-on does not support English yet, so you can reproduce this issue by assigning the Ctrl+numeric keyboard shortcut to any other function