[A11y] Treat last character as 'end of buffer'#11122
Conversation
|
@lhecker you're generally really good about finding ways to simplify code down a lot. Mind taking a look here? I'm worried I overcomplicated some things, and a fresh pair of eyes would be good 😊 |
src/types/UiaTextRangeBase.cpp
Outdated
| return Viewport::FromDimensions({ 0, 0 }, width, height); | ||
| } | ||
|
|
||
| const til::point UiaTextRangeBase::_getDocumentEnd() const noexcept |
There was a problem hiding this comment.
Idea: I could cache _getDocumentEnd(), and in the scope exit for (un)locking the console, I could reset the cache
Worth pursuing?
There was a problem hiding this comment.
I might add the description from the body of this PR here, since this is kinda a load-bearing function
We consider the "document end" to be the line beneath the cursor or last legible character (whichever is further down). In the event where the last legible character is on the last line of the buffer, we use the "end exclusive" position (left-most point on a line one past the end of the buffer).
|
I find this PR a bit hard to understand (at least in diff form). |
|
Please note that nvaccess/nvda#12808 applies, but I'm not sure if this is on your side or theirs. |
zadjii-msft
left a comment
There was a problem hiding this comment.
Okay I've got nits, but these don't matter. I definitely didn't read UiaTests.csv because I trust you know that these do the right thing.
| TRUE,9,TextUnit_Word,-1,endExclusive,endExclusive,-1,segment4LmidDocEnd,segment4LmidDocEnd,TRUE | ||
| TRUE,9,TextUnit_Word,0,endExclusive,endExclusive,0,docEnd,docEnd,FALSE | ||
| TRUE,9,TextUnit_Word,1,endExclusive,endExclusive,0,docEnd,docEnd,FALSE | ||
| TRUE,9,TextUnit_Word,5,endExclusive,endExclusive,0,docEnd,docEnd,FALSE |
src/types/UiaTextRangeBase.cpp
Outdated
| const auto& buffer{ _pData->GetTextBuffer() }; | ||
| const auto lastCharPos{ buffer.GetLastNonSpaceCharacter(optBufferSize) }; | ||
| const auto cursorPos{ buffer.GetCursor().GetPosition() }; | ||
| return { optBufferSize.Left(), std::max(lastCharPos.Y, cursorPos.Y) + 1 }; |
There was a problem hiding this comment.
isn't optBufferSize.Left() always 0?
There was a problem hiding this comment.
yeah. I've been trying to use .Left() instead of 0 hoping that it would make things more clear. But idk if there's a real benefit to that. Should I change it?
src/types/UiaTextRangeBase.cpp
Outdated
| return Viewport::FromDimensions({ 0, 0 }, width, height); | ||
| } | ||
|
|
||
| const til::point UiaTextRangeBase::_getDocumentEnd() const noexcept |
There was a problem hiding this comment.
I might add the description from the body of this PR here, since this is kinda a load-bearing function
We consider the "document end" to be the line beneath the cursor or last legible character (whichever is further down). In the event where the last legible character is on the last line of the buffer, we use the "end exclusive" position (left-most point on a line one past the end of the buffer).
src/interactivity/win32/ut_interactivity_win32/UiaTextRangeTests.cpp
Outdated
Show resolved
Hide resolved
| if (bufferSize.CompareInBounds(_start, documentEnd, true) > 0) | ||
| { | ||
| _start = documentEnd; | ||
| } |
There was a problem hiding this comment.
Man.... we really need to have these things using til::rectangle and have a reasonable clamp method don't we. :(
There was a problem hiding this comment.
Yeah, I'd love to beef up til::rectangle, til::size, and til::point to be able to clamp and walk through bounds more easily. But unfortunately a lot of that work is blocked by making Viewport a til::rectangle.
Actually, are we tracking that anywhere? Just about every time I work on a11y, I find new things I want to add to these TIL structs.
There was a problem hiding this comment.
#4015 is my record of "we still need to kill Viewport"
|
Hello @carlos-zamora! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
|
🎉 Handy links: |
…(Windows 11 Sun Valley 2) (#10964) Supersedes #9771 and #10716. Closes #1682. Closes #8653. Closes #9867. Closes #11172. Closes #11554. Summary of the issue: Microsoft has significantly improved performance and reliability of UIA console: * microsoft/terminal#4018 is an almost complete rewrite of the UIA code which makes the console's UIA implementation more closely align with the API specification. * microsoft/terminal#10886, microsoft/terminal#10925, and microsoft/terminal#11253 form a robust testing methodology for the UIA implementation, including bug fixes in response to newly added tests based on Word's UIA implementation. * microsoft/terminal#11122 removes the thousands of empty lines at the end of the console buffer, significantly improving performance and stability. Since all console text ranges are now within the text buffer's bounds, it is no longer possible for console to crash due to the manipulation by UIA clients of an out-of-bounds text range. * Countless other accessibility-related PRs too numerous to list here. We should enable UIA support on new Windows Console builds by default for performance improvement and controllable password suppression. Description of how this pull request fixes the issue: This PR: * Exposes all three options for the UIA console feature flag in the UI (replaces the UIA check box with a combo box). * Adds a runtime check to test if `apiLevel >= FORMATTED`, and use UIA in this case when the user preference is auto. This is the case on Windows 11 Sun Valley 2 (SV2) available now in beta and set for release in the second half of 2022.
Summary of the Pull Request
Updates our
UiaTextRangeto no longer treat the end of the buffer as the "document end". Instead, we consider the "document end" to be the line beneath the cursor or last legible character (whichever is further down). In the event where the last legible character is on the last line of the buffer, we use the "end exclusive" position (left-most point on a line one past the end of the buffer).When movement of any kind occurs, we clamp each endpoint to the document end. Since the document end is an actual spot in the buffer (most of the time), this should improve stability because we shouldn't be pointing out-of-bounds anymore.
The biggest benefit is that this significantly improves the performance of word navigation because screen readers no longer have to take into account the whitespace following the end of the prompt.
Word navigation tests were added to the
TestTableWriter(see #10886). 24 of the 85 tests were failing, however, they don't seem to interact with the document end, so I've marked them as skip and will fix them in a follow-up. This PR is large enough as-is, so I'm hoping I can take time in the follow-up to clean some things on the side (akapreventBoundaryandallowBottomExclusivebeing used interchangeably).References
#7000 - Epic
Closes #6986
Closes #10925
Validation Steps Performed