Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

UIA in Windows consoles: current character does not show up in braille #10035

Closed
LeonarddeR opened this issue Aug 5, 2019 · 0 comments · Fixed by #10057
Closed

UIA in Windows consoles: current character does not show up in braille #10035

LeonarddeR opened this issue Aug 5, 2019 · 0 comments · Fixed by #10057
Labels
feature/windows-command-console
Milestone
2019.3

Comments

@LeonarddeR
Copy link
Collaborator

cc @codeofdusk

Steps to reproduce:

  1. With braille enabled, open a windows console with UIA enabled
  2. type hello
  3. Press left arrow multiple times.

Actual behavior:

Braille does not show the character the caret is at. When hello was typed, the whole word is shown. However, when pressing left arrow N times, the result after the prompt is as follows:

  1. hell
  2. helo
  3. helo
  4. hllo
  5. ello

Expected behavior:

The current character is not stripped from braille output

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

alpha-18290

Windows version:

Windows 10 1903 build 18362.239

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

Command prompt (cmd)

Other questions

Does the issue still occur after restarting your PC?

Yes

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

No
This was referenced Aug 6, 2019
Closed
Merged
@nvaccessAuto nvaccessAuto added this to the 2019.3 milestone Aug 12, 2019
feerrenrut pushed a commit that referenced this issue Aug 12, 2019
@codeofdusk @feerrenrut
UIA in Win Console: fix setEndPoint/compareEndPoints (PR #10057)
39d20e2 
Closes #10035
Related to #9614
Identical to #10043

Works around a UIA bug on Windows 10 1803 and later that means we can
not trust the "end" endpoint of a collapsed (empty) text range for comparisons. 
The console incorrectly reports the "end" as being past the "start" endpoint.

This stops braille being able to properly track the system caret in Windows Console.

Instead use getText(1) on the textRange to attempt to fetch 1 character.
getText returns an empty string for a collapsed range. By definition, the "start" and
"end" endpoints for a collapsed range are equivalent, thus read from the "start"
endpoint of a collapsed range instead of the "end" endpoint.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature/windows-command-console
Projects
None yet
Milestone
2019.3
2 participants
@LeonarddeR @nvaccessAuto