[Accessibility] Character is not read properly in terminal input after auto-completion

[jooyoungseo]

CC @isidorn

Found the following issue in both NVDA and JAWS.

Closely related to #131090.

Does this issue occur when all extensions are disabled?: Yes

System Info

Version: 1.60.0-insider (system setup)
Commit: 89bbd37
Date: 2021-08-20T17:51:50.560Z
Electron: 13.1.8
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19043

Steps to Reproduce

1. Open VSCode with NVDA.
2. Open terminal by pressing Ctrl+`.
3. Type touch foo.txt to create a new file.
4. Once the file is created, type fo and hit Tab key to auto-complete foo.txt in terminal input. [do NOT hit Enter yet]
5. To change the file extension, press left-arrow key to identify ".txt".

• Notes: Focused character is not read as intended. This issue occurs only after auto-completion event is triggered.

In contrast, the following usecase does not cause this issue:

1. Manually type foo.txt in terminal and hit left-/right-arrow keys.

• Notes: Focused character is read properly this time.

[isidorn]

@jooyoungseo thanks a lot for creating the issue!

I can reproduce this also for my PowerShell terminal on Windows.
The issues seems that auto completion in the Terminal messes up the character navigation announcement, so that when you navigate character by character the wrong character gets read out.

@Tyriar there might have already been an issue like this, this sounds familiar, maybe we already discussed it?

[Tyriar]

I did look into this before and it's kind of difficult because of how it's not a real textarea and we don't know what the actual prompt is. Maybe we could special case left/right to read the character if it resulted in a cursor move or something.

[Tyriar]

This is happening because when you hit tab, we clear the backing textarea which is the reason why left/right work sometimes. This is to prevent some weird state and causing a lot of confusion, we just bail out and clear it all together.

After chatting with @meganrogge I think we can move forward on this when we support shell integration (#133084) as that will enable us to know exactly what the prompt input is and we know where the cursor is so we could keep the textarea in sync.

[isidorn]

Thanks for the update @Tyriar
Makes sense to introduce this after we have support for shell integration.

[Tyriar]

We would also want to cover other cases like up/down changing the prompt history entry (#94708)

[meganrogge]

This should work now

[bhavyaus]

I'm still seeing incorrect character read-out when I manually type foo.txt and use up/down arrows to navigate characters on Windows PowerShell.

[meganrogge]

@bhavyaus a gif would be helpful with terminal.integrated.developer.devMode enabled pls.