Control key gets stuck after using Clipboard History

[MarcoZehe]

Steps to reproduce:

1. In Windows 10 1809 or later, turn on Clipboard History through Clipboard Settings in Windows Settings.
2. Copy some bits of text.
3. Press WindowsKey+V to open Clipboard History, choose an item, and paste it using Enter.
4. Continue working.

Actual behavior:

Sometimes, not always, the keyboard now behaves as if the control key got stuck. Arrow keys left and right will move by word instead of character, up and down will move by paragraph, and letters act as if the control key was pressed alongside. You have to tap the control key once to un-stick it.

Expected behavior:

The keyboard should behave normally.

System configuration

NVDA installed/portable/running from source:

Installed.

NVDA version:

Seen it in any version since 2018.4 up to 2019.3 alphas.

Windows version:

1809, 1903, 1909, and even the insider builds of 2004.

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

Firefox, NotePad, NotePad++, Word.

Other information about your system:

Happens on two quite different systems, a Dell XPS15-9560 (2017) as well as a Microsoft Surface Laptop 2.

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.

See above.

Microsoft feedback for this issue

[MarcoZehe]

CC @josephsl Maybe you have seen this?

[Brian1Gaff]

This is not new, I've seen this sort of thing apparently randomly in Windows 7 as well, but usually when a word processor is running.

Might be some odd effect due to the way nvda can hook into some routines perhaps? 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. Newsgroup monitored: alt.comp.blind-users ----- Original Message ----- From: "Marco Zehe" notifications@github.com To: "nvaccess/nvda" nvda@noreply.github.com Cc: "Subscribed" subscribed@noreply.github.com Sent: Sunday, December 08, 2019 9:26 AM Subject: [nvaccess/nvda] Control key gets stuck after using Clipboard History (#10588)

Steps to reproduce:

1. In Windows 10 1809 or later, turn on Clipboard History through Clipboard Settings in Windows Settings.
2. Copy some bits of text.
3. Press WindowsKey+V to open Clipboard History, choose an item, and paste it using Enter.
4. Continue working.

Actual behavior:

Sometimes, not always, the keyboard now behaves as if the control key got stuck. Arrow keys left and right will move by word instead of character, up and down will move by paragraph, and letters act as if the control key was pressed alongside. You have to tap the control key once to un-stick it.

Expected behavior:

The keyboard should behave normally.

System configuration

NVDA installed/portable/running from source:

Installed.

NVDA version:

Seen it in any version since 2018.4 up to 2019.3 alphas.

Windows version:

1809, 1903, 1909, and even the insider builds of 2004.

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

Firefox, NotePad, NotePad++, Word.

Other information about your system:

Happens on two quite different systems, a Dell XPS15-9560 (2017) as well as a Microsoft Surface Laptop 2.

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.

See above.

Microsoft feedback for this issue

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/10588

[Qchristensen]

Just to confirm, I can replicate this with NVDA, and pressing control once seems to fix it.

I can't replicate with Narrator, or without any screenreader running. There is no error or anything unusual in the NVDA log:

IO - inputCore.InputManager.executeGesture (11:01:52.356) - winInputHook (20872): Input: kb(desktop):enter IO - inputCore.InputManager.executeGesture (11:01:52.414) - winInputHook (20872): Input: kb(desktop):control+v IO - inputCore.InputManager.executeGesture (11:01:53.877) - winInputHook (20872): Input: kb(desktop):control+leftArrow DEBUG - editableText.EditableText._hasCaretMoved (11:01:53.915) - MainThread (12208): Caret move detected using event. Elapsed: 0 ms IO - speech.speak (11:01:53.934) - MainThread (12208): Speaking [LangChangeCommand ('en'), 'the ']

(The ENTER is when I made a choice in the clipboard dialog).

[MarcoZehe]

Confirming that I cannot replicate with Narrator.

[CyrilleB79]

I did not test with the clipboard history but I have already encountered modifier key remaining in down state randomly. To go out of this situation, I press one by one the modifiers keys (ctrl, shift, windows, alt left and right versions). This has already happened with any of the modifier key. I did not find any situation where the issue could be reproduced, so I have not opened an issue for this. For information, I am using Win10 (1709 or 1903).

[Brian1Gaff]

I'd confirm that nothing is in the log at all. Its as if something memorises the state or fails to cancel it but its really random in windows 7. I don't think its new, it used to occur in xp way back but seemed to get less likely until relatively recently for some weird reason.

I don't know where to go with that. Its not happened today though, and sometimes other oddities occur like double speaking of file names in explorer, or missing text in sub menus. It often seems more likely to happen in goldwave 32 bit as well.

Its a brave person who might suggest the cause for these strange goings on, but rebooting nvda, or logging out of the user then back in can fix all of it. 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. Newsgroup monitored: alt.comp.blind-users

---

[kara-louise]

Bumping this issue as this is still a problem with the latest NVDA alpha build (alpha-21587,98892856). I'm running windows 10 home Version 20H2 (OS Build 19042.685). A related issue I have noticed is after pressing enter to paste an item from Clipboard History, only the letter v gets inserted. This may happen instead of the issue @MarcoZehe mentioned, or at the same time, or if you're lucky the text will just get pasted. This does not happen with Narrator

[josephsl]

Hi, a workaround is pressing Space instead of Enter to paste items from clipboard history. Thanks.

From: kara-louise notifications@github.com Sent: Sunday, January 3, 2021 12:10 PM To: nvaccess/nvda nvda@noreply.github.com Cc: Joseph Lee joseph.lee22590@gmail.com; Mention mention@noreply.github.com Subject: Re: [nvaccess/nvda] Control key gets stuck after using Clipboard History (#10588)

Bumping this issue as this is still a problem with the latest NVDA alpha build (alpha-21587,98892856). I'm running windows 10 home Version 20H2 (OS Build 19042.685). A related issue I have noticed is after pressing enter to paste an item from Clipboard History, only the letter v gets inserted. This may happen instead of the issue @MarcoZehe https://github.com/MarcoZehe mentioned, or at the same time, or if you're lucky the text will just get pasted. This does not happen with Narrator

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/10588#issuecomment-753669673 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4AXECQQDSY7YY6PFVXM3TSYDFJTANCNFSM4JXZJOOA .

[kara-louise]

Has there been any developments on fixing this issue? the workaround @josephsl mentioned is fine for what it is, but a permanent fix is needed.

[Adriani90]

cc: @feerrenrut

[mltony]

I have spent some time investigating this, and now I know why this bug is happening, but I don't know how to properly fix this. More investigation is needed in case someone else has time. Here is what happens. Every keystroke NVDA receives can have injected flag on or off. When the flag is off, then NVDA will process keystroke no matter what. When injected flag is on however, then NVDA will process keystroke unless ignoreInjected in keyboardHandler is True, in which case keystroke will be ignored. So the way clipboard history works is that right after selecting an entry and pressing enter, it substitutes current clipboard and simulates control+v, that is NVDA receives control+v keystroke (well it rather receives series of keyboard events: control down, v down, v up, control up), all with injected flag. Now we need to figure out why ignoreInjected=True while some of these four events are processed. It turns out this is how gesture.send() method is implemented: it first sets ignoreInjected flag to true, then it resends the same gesture (which NVDA receives and ignores), then it sets ignoreInjected back to false. It turns that pressing Enter while in clipboard history triggers EditableText.script_caret_moveByLine, which in turn calls EditableText._caretMovementScriptHelper, that in turn calls gesture.send(), which sets ignoreInjected=True for some time just to resend Enter keystroke. Then a race condition happens: depending on the timing, a few things might happen:

1. control down, IgnoreInjected set to True, v down, v up, control up, ignore Injected set to false - In this case control key will get stuck - that is NVDA would think that control key is down.
2. IgnoreInjected set to True, control down, IgnoreInjected set to False, v down, v up, control up - in this case nothing is pasted, but letter v is printed instead I observe both options on my computer, along with some times when pasting behaves correctly. Now one important question is why EditableText.script_caret_moveByLine is triggered while clipboard history is a list view? I actually don't have a good answer to this question. In my case I am trying to paste into either notepad or notepad++, which would indeed be represented by EditableText class, but I don't understand why upon pressing enter the currently focused clipboard history wihdow magically disappears and the keystroke is processed by EditableText. By the way now I also understand why Joseph's workaround works: it just happens that in EditableText there is a shortcut for Enter, that internally does gesture.send(), while for spacebar, there is no such shortcut, and therefore ignoreInjected flag is never set. It seems the next step in investigating this should be to figure out why Enter keystroke is processed by EditableText, and not UIA ListItem. If this problem is fixed then we'd need to make sure that no gesture .send() is being called on Enter, which is probably the case anyway.

[josephsl]

Hi, this is because focus stays in the edit field while navigator object is set to a clipboard history item. This is by design: emoji panel and clipboard history in Windows 10 series (not Windows 11) is an overlay, and when focus moves to the just opened panel, NVDA will forget where you are when the panel closes. A workaround (implemented for Windows 11 in Windows App Essentials) is detecting emoji panel window closure, which then causes NVDA to queue a gain focus event for focusObject.objectWithFocus (this attribute reports system focus as reported by the system itself, not by NVDA). Note that in Windows 11, because system focus moves to emoji panel/clipboard history when the panel opens, Enter key will work. Thanks.

[Adriani90]

@kara-louise, @mltony, @CyrilleB79 are you still seeing this issue? I guess this is only reproducible in Windows 10 right? @josephsl any updates from your side?

[CyrilleB79]

I am not a user of clipboard history so won't be able to provide a status on this specific use case.

Regarding the broader of a modifier key remaining in the "pressed" state, I have still encountered it recently, even if probably quite rarely (less frequently than in the past). Given the explanations above, I guess that various issues could lead to the same symptom.