windows terminal: NVDA reads invisible lines when using pagers such as less and more

[OSadovy]

Steps to reproduce:

1. launch windows terminal with wsl2 (tested with ubuntu 20.04)
2. run command which pages its output, for example man test
3. press nvda+numpad7, observe that NVDA navigated to the beginning of man output with command synopsis: press numpad9 a few times to hear "TEST(1) User Commands TEST(1)"
4. press space bar to scroll the page down, you may repeat a few times to see the full effect
5. press shift+numpad7 again to go to the top
6. try to read following lines, press numpad9

Actual behavior:

NVDA reads the command output from the very beginning, as if no pagination appeared: "TEST(1) User Commands TEST(1)"

Expected behavior:

NVDA should read only the last page displayed. It worked like that before and it also works like that when using wsl in windows console (without the new windows terminal)

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2021.3

Windows version:

windows 10 21H1 (os build 19043.1348)

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

Microsoft windows terminal 1.11.2921.0

Other information about your system:

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.

I think it worked in 2020.4

If NVDA add-ons are disabled, is your problem still occurring?

N/A

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

N/A

[OSadovy]

Tested, the issue does not occur with NVDA 2021.2

[codeofdusk]

Not a bug, see PR #12669. Will be enabled as well in modern versions of Windows Console with #10964.

[OSadovy]

@codeofdusk could we please make it configurable? Not being able to reliably jump to the top of visible area to review the output line by line breaks experience when using terminal-based programs a lot. e.g. imagine reading git log page by page, however when one switches to the next page they can not review content of that page from top to bottom, since NVDA treats the output as a whole. the same can be said for using man and basically any interactive-type program where the user needs to granularly navigate the output.

[codeofdusk]

As an idea, see the visi-range-commands branch on my fork. I've added (global for now) scripts to jump to the first/last visible line in UIA text controls. Does this help/is this the right approach? Cc @LeonarddeR, @seanbudd, @carlos-zamora.

[OSadovy]

@codeofdusk Thank you for considering approaches to address the issue!

I am not sure that adding a separate commands for this is the best experience. It suggests that we assume by default the user wants to jump to the top/bottom without taking into account visible range, which is not necessarily the case. It might be subjective, but I can't imagine good workflow examples from top of my head where I might prefer such a behavior by default when using terminal, while I use it everyday for years.

A couple ideas:

1. make jump to top/jump to bottom use visible ranges by default, add scripts to jump to top/bottom skipping them. It assumes that user might sometimes want to jump to the absolute top/bottom but still prefers most of the time to be limited by what is visible.
2. Make jump to top/bottom scripts to use visible ranges when pressed single time, and jump to the absolute top/bottom when pressed second time.

In any scenario, we might also allow the user to navigate out of the visible range by using next/previous line/word/character commands.

This way we:

• do not break experience for hard-time terminal users
• Allow the user to have flexibility to read the whole content of terminal window if they so desire (including copying the output to the clipboard etc)
• Address the concern of some lines displayed out of the visible range being completely inaccessible to NVDA

[codeofdusk]

I think the problem with both of these ideas is that they cause terminals to have different behaviour from the rest of NVDA, which has caused user confusion. With upstream changes to the terminal, this differentiation is no longer necessary, so #12669 brings newer UIA terminals in line with other UIA controls. The original reason for bounding to start with was that older (IMPROVED and END_INCLUSIVE) UIA consoles had many thousands of empty lines at the end of the text. I tried adding configurable review bounds (see PRs #9687 and #9735) but those approaches were rejected.

One approach for idea 1 could be to bring back a ConsoleUIATextInfo for FORMATTED consoles and wt, with POSITION_FIRST and POSITION_LAST relative to the visible (not document) range. This would make review work as specified but I'm not sure if this has other unintended consequences.

For idea 2, do scripts on the object level override globalCommands?

CC @michaelDCurran.

[OSadovy]

Thanks for references, now I see that we had an approach in the past to address the issue by making bounding configurable with a global gesture.

I'd argue that #12669 reasoning is not 100% precise regarding bringing the console review in precedent with the rest of NVDA. In word and web documents there is an independent cursor which does not lose its position when navigating down (as is the case when using pagers in the terminal); there also exists commands to move up and down by pages (again not the case with the terminal).
with the current implementation, when navigating to the next page using a pager in Windows Terminal, one loses the review position and there is no way to reliably restore it (which was possible by jumping to the top when that command was bounded by visible offsets). It is not the case with word or web documents.
In other words, those other places provide very different experience and should not be compared directly without taking into account the context.

I see that @michaelDCurran was in favor of the global gesture so he clearly recognized the problem, let's wait what he has to say for this as well.

[alex19EP]

As a linux user who rarely uses windows, I would like to say that this change really makes it difficult to use the terminal as conveniently as I do on linux.

when windows received a normal terminal, I was very happy, but since recently, when this change has appeared, working in the windows terminal causes me only discomfort.

[codeofdusk]

To clarify:

• Add new scripts to move review cursor by page #14021 adds new scripts to move the NVDA review cursor by page.
• Windows Terminal plans to implement support for movement by page very soon, see UIA: support movement by page microsoft/terminal#13756.
• Once movement by page is available in wt, the new scripts can be used to move by visible screen of output.

[mltony]

@codeofdusk, shall this be reopoened? I just checked with my Windows 11 terminal and I can still reproduce this issue: Shift+7 takes me to the very beginning of the buffer instead of the first visible line. From what I can see:

• Your PR @13671 has never been merged.
• UIA: support movement by page microsoft/terminal#13756 appears to have been abandoned and @carlos-zamora didn't respond to me.

Or am I missing anything?

[RDMurray]

Is there any progress on this?

I must admit I don't understand why a screen reader would, by default, read content that isn't on the screen and provide no way to navigate to the top of the visible content. It makes using a pager, or any full screen text UI very difficult.

Are there any alternative terminals for windows that don't have this problem? I use teraterm for remote ssh connections.

[cary-rowen]

@RDMurray
I'm using Putty.

[mltony]

FWIW I just released Console Toolkit v1.3 add-on where I implemented a workaround for this issue. In UIA terminals it overrides shift+numpad7 command and it takes you to the first visible line. Double press will take you to the very beginning of the buffer.

[cary-rowen]

Thanks @mltony

[RDMurray]

Thanks @mltony that will make the terminal usable again. I really hope a similar solution can be included in NVDA; it is essential to be able to navigate to the top of the visible window when working in a terminal.

[mltony]

The change is quite straightforward from technical point of view. The challenging part would be to get an agreement on what should be the UI for this change. IIRC Sean had concerns of this behavior for shift+numpad7 be inconsistent with behavior in all other applications. If anyone is willing to drive this discussion - I can implement NVDA core PR when an agreement is reached.

[codeofdusk]

I also have concerns about this behaviour, and agree that a "jump to first visible"/"jump to last visible" is needed.

@carlos-zamora do you have any updates on microsoft/terminal#13756?