NVDA reading out words it shouldn't if 'speak typed words' is on

[TechHorseG]

Win 10 / NVDA portable 2019.2 / Laptop layout

Hello. with the title setting on I notice the following odd behaviour. If I click on an empty area on the desktop and press some keys, for example "xyz" then space, NVDA will rread out "xyz" as if this was a text document and I had typed these four keys.

This happens in other apps. For example in File Explorer if I press "a" and no file begins with "a", then press space, I hear that "a" being read out.

In NVDA's own speech viewer I can type characters into the read-only output, press space and hear them read back.

This doesn't seem to happen when the pressed key has a legitimate effect. For example, if I press "a" in FileExplorer and there actually is a file beginning with "a" for the focus to move to, then when I press space I won't hear that "a" spoken back to me.

If however there is only one file beginning with "a", and I press "a" three times then space, I will hear two "a"s. If there are two files then I can press "a" multiple times and not hear any of them read back to me when I press space.

Narrator didn't do this. It only spoke the words I had typed if they were typed into a valid text box.

It has also gotten me a bit worried for security reasons. If NVDA can read out the "hello" I typed into the desktop, or its own speech viewer, then clearly that "hello" I typed must be being stored somewhere. Do I need to worry about password security for instance?

Thanks.

[DrSooom]

Do I need to worry about password security for instance?

NVDA (as well as almost all other screen readers) is able to log nearly all typed keys if the log level is set to "Input/Output" or "Debug". Therefore I suggest to completely disable it if you don't need it. The default log level is "Info". Typed keys aren't logged on that level.

[TechHorseG]

Thanks, although even with log level disabled the behaviour I mentioned persists. So I would still like to have this here as a bug report. NVDA should only speak out the words that are typed into a text field. It should neither speak, nor retain any memory of characters that are typed 'into the ether' (unless if the relevant logging options are set).

[Adriani90]

I can reproduce this issue in NVDA alpha-18874,6cdb7be0
This should definitely be only the case in edit fields which are not password fields and should not occur globally.
cc: @JulienCochuyt, @feerrenrut

[DrSooom]

This behavior also exists with NVDA 2018.1 on win7x64 (quick test in Windows Explorer). (I hate such keyboard input speech echo feedbacks. Therefore I disable them all in every screen reader.)

[bhavyashah]

I can confirm that tis issue persists with NVDA version 2020.2 Beta 1. I tested this quickly on the Desktop on a Windows 8.1 system. As far as my memory goes, I have been experiencing this behaviour since many, many years, probably as far back as 2015. Hence, I am fairly certain that this is not a newly introduced regression.
Commenting on the impact of this issue, I think this can be genuinely confusing for new users. Even though the name is self-explanatory, I strongly suspect that a majority of users don't exactly know what a read only field is. In fact, the nature of navigating a read only field is so similar to an edit box, that I think it wouldn't be difficult to conflate the two. Furthermore, the fact that this bug occurs on the Desktop, in Windows Explorer, and other commonly accessed places on the computer, is noteworthy. So while the direct impact of this issue is limited, it manifests pervasively and is likely to perplex new users.

[JulienCochuyt]

Looking at how this is implemented, it appears NVDA is attempting to speak typed words in any given control, whatever its role is, until the control looses focus. I guess this is done to avoid missing to announce typed words in unknown controls.
This explains why no word is spoken on the desktop or file explorer when a typed letter matches the initial of an icon or file: There is a focus change.

IMHO, this could be change to trigger announce of typed words only for the following roles:

• ROLE_EDITABLETEXT (without state STATE_READONLY)
• ROLE_TERMINAL
• ROLE_UNKNOWN

@michaelDCurran do you think this is worth giving a reasonable try, or can you think of cases where this would lead to a regression?

[Adriani90]

cc: @seanbudd, @gerald-hartig can you please prioritize this accordingly? This has indeed security implications, especially when typing letters of a password accidentally in a non edit field and the speak typed characters or typed words is on.
These should be spoken really only in edit fields where typed characters / words are visible on the screen.
cc: @jcsteh maybe you have some insights as well?

[CyrilleB79]

It's worth noting that when NVDA detects a freeze (watchdog), NVDA still reports typed words in some situations.

The consequence in real life is that sometimes I have had passwords reported when typing them because NVDA was in a short freeze state while typing a password.
The short freeze was probably not an NVDA bug, since I have many add-ons. But during micro-freezes NVDA is not able to evaluate if typing should be reported so it should be disabled by default.

cc @gerald-hartig for awareness

[jcsteh]

Do I need to worry about password security for instance?

No. Assuming a password field is marked correctly by the application, NVDA explicitly detects this and does not store or report the typed characters (unless full i/o logging is enabled, but that would only be done for debugging purposes and is not enabled by default).

It's worth noting that when NVDA detects a freeze (watchdog), NVDA still reports typed words in some situations.
The consequence in real life is that sometimes I have had passwords reported when typing them because NVDA was in a short freeze state while typing a password.

watchdog shouldn't act unless an app has been frozen for more than 10 seconds. The only time this delay is shortened is if you are switching foreground windows, but in that case, typing a password without waiting for speech isn't a great idea anyway, since you can't be certain you are typing into a password field. Can you provide more details about the scenarios in which this occurs?

All of that said, it should be fairly straightforward to:

1. Be absolutely certain that typed characters don't get queued if watchdog has detected a freeze. This could be done in NVDAHelper.nvdaControllerInternal_typedCharacterNotify by checking watchdog.isAttemptingRecovery. At this stage, I don't see how this could be a security concern, but that might change depending on the response to the above question.
2. Only report typed words for specific roles. This would need to be done by checking the focus object in speech.speech.speakTypedCharacters. I also don't think this is a security concern because of the explicit password field checks already implemented.

[CyrilleB79]

It happens when I connect on the webpage of my e-mail provider's webpage (https://www.laposte.net/accueil):

• I first type my username in the edit field
• then I press enter; this makes the password field appear and focused
• then I type my password and then Enter

Since I know the page and am used to it, I do not expect to hear the role of the control being focused. I type username, Enter, password and Enter without waiting for an audio feedback.

[XLTechie]

And, I will add that @CyrilleB79's usage pattern here, is not at all uncommon among skilled users. When 90% of the time you know what is going to be said after performing a certain action, you often want to make up speed there that you will likely later lose in other tasks where you do have to listen.

[jcsteh]

That's fine, but that isn't a foreground window switch, which means it shouldn't be a watchdog freeze recovery (see my comment above for the reasons). So something else is going on there that isn't related to watchdog. That doesn't invalidate the issue, but it does mean it needs additional diagnosis.

[jcsteh]

It may just be that the focus events take a while to arrive and your key presses get buffered until that happens. But I don't really know what we can do about that because when your key presses occurred, the username field probably still had focus as far as NVDA was concerned, so even if we disabled typed words for most things, you'd still hit this problem. The pattern of ignoring output is common among skilled users, yes, but when it comes to passwords, all users (even sighted ones) accept a certain amount of risk if they just start typing without checking to see that their password is actually being masked. Perhaps when you press enter, the username doesn't submit immediately and your typed characters actually end up going into the username field.

[CyrilleB79]

Perhaps when you press enter, the username doesn't submit immediately and your typed characters actually end up going into the username field.

No, the characters of the password are (or may be) echoed. But I can confirm that these characters end up in the password field that has just appeared, because the password check is OK.