UI Automation in Windows Console: make speaking of passwords configurable

[codeofdusk]

Link to issue number:

Split from #9646 (builds on #9614).

Summary of the issue:

Currently, in consoles with UI Automation enabled:

• When "speak typed characters" or "speak typed words" is enabled, typed text that is not displayed onscreen (such as passwords) is still reported.

Description of how this pull request fixes the issue:

When "speak passwords in UIA consoles" is disabled and one of "speak typed characters" or "speak typed words" is enabled, typedCharacter events are trapped and queued until a textChange event is received. In winConsoleUIA.event_textChange, typed characters are removed from the queue and typedCharacter events are fired. In winConsoleUIA.script_clear_isTyping, this queue is flushed. Since password prompts do not update the screen while the user is typing, no textChange events are received, so no typedCharacter events are fired and therefore no characters are announced.

Testing performed:

Tested password entry (by authenticating with ssh) on Windows 10 versions 1803 and 1903.

Known issues with pull request:

• When "speak passwords in UIA consoles" is disabled and one of "speak typed characters" or "speak typed words" is enabled, typedCharacter events are only dispatched once textChange is received. This may introduce a small performance penalty.

See #9646 for all UIA console known issues to date.

Change log entry:

None.

[codeofdusk]

CC @feerrenrut, @LeonarddeR, @michaelDCurran.

[LeonarddeR]

For reference, may be you could elaborate on why passwords aren't spoken with the legacy implementation, and why this method does not work for UIA console?

[codeofdusk]

For reference, may be you could elaborate on why passwords aren't spoken with the legacy implementation, and why this method does not work for UIA console?

The legacy console support implements "speak typed characters" by looking at the proximity of new text to the caret. If characters appear close to the caret, they are presumed to be typed characters and read out as such. While this prevents typed passwords (or other off-screen characters) from being announced, it leads to #513. The UIA console captures typed characters using keyboardHandler, which has no way of knowing whether a character actually caused the screen to update.

[michaelDCurran]

Before merging this, I'd like to know whether you do notice a lag in speak typed characters when speak passwords is off?

[codeofdusk]

Not really on my system, but it’s theoretically possible. Bill

…

On 2 Jun 2019, at 20:38, Michael Curran ***@***.***> wrote: Before merging this, I'd like to know whether you do notice a lag in speak typed characters when speak passwords is off? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9649?email_source=notifications&email_token=AAS4QS2RGL27YPP2RQWFD2TPYRR2BA5CNFSM4HRYFPRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWYBPKY#issuecomment-498079659>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAS4QS7JM4QXRO7NP7H5D33PYRR2BANCNFSM4HRYFPRA>.

[michaelDCurran]

You'll need to merge master into this branch and fix conflicts before I can merge this. Conflicts probably due to the merging of pr #9651

[michaelDCurran]

In gui/settingsDialogs.py:
You need to change both haveConfigDefaultsBeenRestored and restoreToDefaults methods on the advancedSettingsPanel class to handle your new setting.