You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
UIA: GetVisibleRanges() returning text beyond the visible range #7803
Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] OpenConsole (relaese build of #7792 )
Windows Terminal version (if applicable):
Any other software? NVDA
UiaTextRanges (UTR) are { inclusive start, exclusive end }. To encompass the first line of the buffer, an UTR would be { (0,0), (0,1) }.
GetVisibleRanges returns the UTR encompassing the viewport.
Creating a degenerate range at the end of the visible viewport means that we have a degenerate range underneath the viewport. This is because the exclusive end is {0, viewport.Height()+1}.
Expanding by line makes you encompass the line that _start is currently on. Since _start = _end, and _end is on the line under the viewport, you encompass the line under the viewport.
The fix is simple: if we have a degenerate range, and we try to expand by line, move _start up instead of _end down.
Dustin L. Howett (@DHowett) This can be added into #7792, if so desired. It would make a minor modification to the "expand by line" change I made, but I would want to add a test that specifically covers these repro steps. It's also small enough that we can make this a separate PR. I'm fine either way. Risk is minor since we would only do this when it's a degenerate range.
So, I attempted to fix this on dev/cazamor/a11y/expand-line-under-viewport. That definitely fixes the bug, but I don't think it's the correct behavior overall. I've summarized in the collapsible section below some concerns with the implementation.
Concerns with my branch
My branch makes it such that a degenerate range at the beginning of a line expands backwards, instead of forwards. Being in the state described in this bug report (degenerate range at the end of the visible ranges) satisfies this case. When you expand by character/line, you now get the last character/line of the visible range. So the bug is fixed.
However, this would introduce another bug/discrepancy. Consider a line being encompassed in a range. Then you move "end" to "start". When you expand by line, I expect the current line to be covered. Instead, it'll cover the previous line. So the question is, when would we distinguish between wanting to expand forwards vs backwards?
It sounds like UIA may be implemented properly for this scenario, and NVDA would have to do the extra work here by moving to the previous character, then expanding by line.
In MS Word, if you have a few paragraphs of text (=lorem(5,5))...
Expand by paragraph
move start to end
NOTE: you are now at the beginning of the next paragraph
expand by line
NOTE: you now have a range of the first line of the next paragraph
ConHost doesn't have paragraph support, but we can kind of equate getting the visible ranges to getting a paragraph in MS Word (because it's a range that expands multiple lines). If that's the case, the current behavior is correct.
Activity
codeofdusk commentedon Oct 2, 2020
Cc Carlos Zamora (@carlos-zamora).
carlos-zamora commentedon Oct 2, 2020
Root Cause
UiaTextRanges (UTR) are { inclusive start, exclusive end }. To encompass the first line of the buffer, an UTR would be { (0,0), (0,1) }.
GetVisibleRangesreturns the UTR encompassing the viewport.Creating a degenerate range at the end of the visible viewport means that we have a degenerate range underneath the viewport. This is because the exclusive end is {0, viewport.Height()+1}.
Expanding by line makes you encompass the line that _start is currently on. Since _start = _end, and _end is on the line under the viewport, you encompass the line under the viewport.
The fix is simple: if we have a degenerate range, and we try to expand by line, move _start up instead of _end down.
Dustin L. Howett (@DHowett) This can be added into #7792, if so desired. It would make a minor modification to the "expand by line" change I made, but I would want to add a test that specifically covers these repro steps. It's also small enough that we can make this a separate PR. I'm fine either way. Risk is minor since we would only do this when it's a degenerate range.
codeofdusk commentedon Oct 2, 2020
I think this will also fix #5481 (which is also separately fixed by nvaccess/nvda#11639).
DHowett commentedon Oct 2, 2020
Separate PR plz
carlos-zamora commentedon Oct 2, 2020
So, I attempted to fix this on
dev/cazamor/a11y/expand-line-under-viewport. That definitely fixes the bug, but I don't think it's the correct behavior overall. I've summarized in the collapsible section below some concerns with the implementation.Concerns with my branch
My branch makes it such that a degenerate range at the beginning of a line expands backwards, instead of forwards. Being in the state described in this bug report (degenerate range at the end of the visible ranges) satisfies this case. When you expand by character/line, you now get the last character/line of the visible range. So the bug is fixed.However, this would introduce another bug/discrepancy. Consider a line being encompassed in a range. Then you move "end" to "start". When you expand by line, I expect the current line to be covered. Instead, it'll cover the previous line. So the question is, when would we distinguish between wanting to expand forwards vs backwards?
It sounds like UIA may be implemented properly for this scenario, and NVDA would have to do the extra work here by moving to the previous character, then expanding by line.
In MS Word, if you have a few paragraphs of text (
=lorem(5,5))...ConHost doesn't have paragraph support, but we can kind of equate getting the visible ranges to getting a paragraph in MS Word (because it's a range that expands multiple lines). If that's the case, the current behavior is correct.
codeofdusk commentedon Oct 2, 2020
These seem to be NVDA issues. See nvaccess/nvda#11722.