search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 637 forks source link

Incoming text in the terminal is not reliably read #11170

Open Neurrone opened 4 years ago

Neurrone commented 4 years ago

CC: @codeofdusk

Steps to reproduce:

  1. Do something that causes at least a screen's worth of text to appear. For example, ls on a directory with 50 entries.

Actual behavior:

Nothing is heard, or only the last few lines of the output is read. I'm not sure what causes the differences, maybe the amount of text being returned?

Expected behavior:

Incoming text is always reliably read.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

Version: alpha-20220,1c4519a6

Windows version:

Windows 10 2004 10.0.19041.264

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

I happened to be operating in WSL2, just mentioning that here in case that happens to matter.

Other information about your system:

This bug doesn't happen with UIA usage in terminals disabled.

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If addons are disabled, is your problem still occuring?

Yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

No

codeofdusk commented 4 years ago

Could you please try the following?

  1. Open Windows Console (with UIA).
  2. Press NVDA+control+z to open a python console.
  3. Enter nav.is21H1Plus

Do you get True or False?

Neurrone commented 4 years ago

It returns false. I'm only on 20H1, not on the fast ring.

codeofdusk commented 4 years ago

It returns False. I'm only on 20H1, not on the fast ring.

OK, try this:

  1. Download Open Console and extract the zip.
  2. Run OpenConsole.exe.
  3. From Open Console, start a Python interpreter with NVDA+control+z. Verify that nav.is21H1Plus returns True for this console.
  4. Attempt to reproduce your issue. (I think you can start WSL from Open Console by typing bash). Let me know if it still occurs under Open Console.
Neurrone commented 4 years ago

It returns true now, but the issue is still happening.

codeofdusk commented 4 years ago

OK, I think this is another instance of/similar to microsoft/terminal#5481. Cc @carlos-zamora.

codeofdusk commented 4 years ago

Just to confirm, could you please run WindowsTerminal.exe from the same archive and try to reproduce the issue from there?

Neurrone commented 4 years ago

Happens as well with WindowsTerminal.exe

codeofdusk commented 4 years ago

Hmmm, could be a different issue. It does work correctly with UIA disabled and "use the new typed character support in Windows Console" enabled, correct?

Neurrone commented 4 years ago

I'm confused now, I suspect there might be 2 bugs going on at the same time.

  1. With UIA enabled, both windows terminal and the normal console are not reading the command that I am testing with properly - they start reading at different parts of the 85 line of output from my ls -al command instead of the start of the output. Additionally, if I execute the same command successively, nothing is read from the second invocation onwards for both terminal and normal console.
  2. Without UIA enabled, both terminal and normal console are reading from halfway in the output as above. Terminal still doesn't read anything for successive invocations of the same command, though regular consule does read part of the output of consecutive invocations of the command (although not reliably - sometimes it only reads out one line).
codeofdusk commented 4 years ago

Terminal (i.e. WindowsTerminal.exe) always uses UIA regardless of user settings as that's all we have available (and Terminal's UIA implementation is very good in any case). For your Windows Console testing, when UIA console is disabled, can you test with the "use the new typed character support" option both enabled and disabled? Does that option make any difference? (UIA Windows Console always uses the new typed character support and is not controlled by that checkbox)

Neurrone commented 4 years ago

I think there might be a difference when the new typed character option is turned on vs off, but not by much. I hear an extra % character being read when executing the same command in succession when the setting is off, but it doesn't materially affect this scenario being broken.

You mention terminal's UIA implementation being really good, do you recommend using terminal over console then? I am encountering bugs but it seems that these bugs are present regardless of which console that I use.

Neurrone commented 4 years ago

I managed to reproduce an issue that I seen before, where even though there is new text being written to the output even if it is a small amount of text, NVDA doesn't echo it at all, which I found pretty disturbing.

I was using curl to test a buggy liveness check for a service (checking that curl returns 200 in response to an API call). Curl outputs the status code that it receives. After a few times of repeating the same command, NVDA just stops reading the incoming text and I remember having to restart NVDA to restore that functionality.

codeofdusk commented 4 years ago

I'll be interested to see how #11639 affects this.

Adriani90 commented 1 year ago

@Neurrone do you still have this issue with NVDA 2023.2?

Neurrone commented 1 year ago

I've still seen this happening when anything UIA related like the start menu doesn't speak at all, requiring a full restart of NVDA.