using orca I can't edit commands already executed in the VSCode terminal

[jvesouza]

Issue Type: Bug

1. In a linux environment launch orca and VSCode.
2. Press ctrl+` to activate a VSCode terminal.
3. Type a shell command and press enter, for example:
   echo This is a test.
4. Press the up arrow.

Orca reads the command typed in the step 3 as expected.

5. Try use left and right arrow to review the content of the command.

Orca should read each character as left and right are pressed but instead it is muted.

@isidorn @joanmarie
I'm not sure if the problem is with orca or VSCode.

VS Code version: Code - Insiders 1.44.0-insider (2aae1f2, 2020-04-07T21:48:49.536Z)
OS version: Linux x64 5.6.2-arch1-2

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Extensions with Orca: pressing enter does not properly pass focus to details (#93720)
• In some situations, the orca is muted when the focus is moved to the file explorer (#91884)
• Orca not reading languages list (#92324)
• Errors and warnings not read out by screen reader when they appear (#93014)
• Orca fails to reliably speak the settings tree (#92488)

[isidorn]

@jvesouza thanks for filling this.
I can reproduce this issue. Orca nicely reads out whatever I type in our integrated terminal, but it does not read it if I use the up / down arrow. @Tyriar might you have an idea? Is there some difference in how you insert text for history entries?

[Tyriar]

I'm not sure we can solve this, at least in the ideal way. The actual "textbox" is owned by whatever process is running (eg. powershell), it could start at cell 2 or cell 10, we don't know. So we can't populate a HTML textbox to expose that information to screen readers.

[jvesouza]

In my environment orca reads when I press up/down arrow. Orca does not read when I press left/right after I press up/down.

[Tyriar]

@jvesouza when you press up, the terminal in VS Code sends the "up" code over to the shell and it responds by moving the cursor to the beginning on the prompt and then printing characters. It's read out the same as how output is read out.

Now when you move the cursor left, VS Code sends the "left" code over to the shell and the shell responds by moving the cursor 1 cell to the left. The way this works in the editor (I think) is that there is a backing textarea which contains all the text in the line so it works just like working in a regular textarea, however in the terminal it's impossible to know reliably what is in the prompt as we don't know what the program is or does, we can only guess.

[jvesouza]

@Tyriar Thank you very much for the excellent explanation. I understood why an ideal solution is not possible.

[isidorn]

@Tyriar thanks for the explanation, and yes this works in the editor as there is a backing textarea which contains all text.
For now let's leave this open as a feature request and due to the limitation @Tyriar pointed out we will probably not tackle in the near future.

[joanmarie]

Funny thing: Very rarely -- and unpredictably -- Orca does speak the character being arrowed to. It does this in response to caret-moved events (which it also gets from VTE-based apps when the user moves left/right on a line with text). Any ideas why most of the time, these needed events are completely missing?

[Tyriar]

@joanmarie your shell might be re-printing the character for example by re-setting the character style, in which case it would be announced.

[joanmarie]

@joanmarie your shell might be re-printing the character for example by re-setting the character style, in which case it would be announced.

Let's take Orca out of the picture for a moment. If my shell is re-printing the character for example by re-setting the character style, who is emitting the accessible object:text-caret-moved event in response to that change? The shell, Chromium, or VSCode?

[Tyriar]

@joanmarie there is a backing textarea in the terminal as well that's used for input, Chromium will emit these events I'm guessing.

[webczat]

Could anyone see if this works on windows? or that is also problematic there? The comments would imply that it is, but... better to make sure.

[Tyriar]

@webczat it probably doesn't on Windows either, it depends what winpty/conpty emits (it gets more complicated over there).

[Tyriar]

This is another case of #131295