-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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.
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
UIA: use full buffer comparison in rects and endpoint setter #6447
Conversation
nit: I'd like the title to explain when, not just say "sometimes" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Please write tests.
- What if they're already at the actual real bottom? Where virtual = actual.
This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment. |
Will commenting here prevent an automatic close? |
This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment. |
Might a similar approach be needed to fix #5481? |
@carlos-zamora Any updates on this PR? |
Hey, sorry. I think I'm going to have to reevaluate some of my open accessibility PRs today. Both of them have to do with defining the end of the document to be the last character. Which means we'll have to update the tests too. I'm leaving this open for now, but expect a better plan later today or tomorrow :) Sorry for the delay! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Please change the name of this PR.
- Your comments explain the what, not the why
- I still don't understand the why
- So, it's possible to navigate character-by-character off the bottom of the viewport? what happens after that?
- What happens when you do this at the actual bottom of the buffer at 9001 lines?
What cases does this open up? When we have an endpoint beyond the visible screen, what happens? What if you move it more? What if you read the range aloud, get its text? |
Co-authored-by: Dustin L. Howett <[email protected]>
Scrolling is of no concern because TermCore clamps the scroll offset to be valid. The text is still extracted properly as you are only extracting spaces when in the non-populated region of the buffer. The main concern is that this lacks polish. We should provide more tests (as you requested earlier), but I've moved that work into a follow-up item to ensure we are treating the end of the buffer correctly and wholistically. |
82c01b3
to
02465e0
Compare
Hello @DHowett! 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 (
|
In UiaTextRange, `_getBufferSize` returns an optimized version of the size of the buffer to be the origin and the last character in the buffer. This is to improve performance on search or checking if you are currently on the last word/line. When setting the endpoint and drawing the bounding rectangles, we should be retrieving the true buffer size. This is because it is still possible to create UiaTextRanges that are outside of this optimized size. The main source of this is `ExpandToEnclosingUnit()` when the unit is `Document`. The end _should_ be the last visible character, but it isn't because that would break our tests. This is an incomplete solution. #6986 is a follow up to completely test and implement the solution. The crash in #6402 was caused by getting the document range (a range of the full text buffer), then moving the end by one character. When we get the document range, we get the optimized size of the buffer (the position of the last character). Moving by one character is valid because the buffer still has more to explore. We then crash from checking if the new position is valid on the **optimized size**, not the **real size**. REFERENCES #6986 - follow up to properly handle/test this "end of buffer" problem Closes #6402 (cherry picked from commit c390b61)
In UiaTextRange, `_getBufferSize` returns an optimized version of the size of the buffer to be the origin and the last character in the buffer. This is to improve performance on search or checking if you are currently on the last word/line. When setting the endpoint and drawing the bounding rectangles, we should be retrieving the true buffer size. This is because it is still possible to create UiaTextRanges that are outside of this optimized size. The main source of this is `ExpandToEnclosingUnit()` when the unit is `Document`. The end _should_ be the last visible character, but it isn't because that would break our tests. This is an incomplete solution. #6986 is a follow up to completely test and implement the solution. The crash in #6402 was caused by getting the document range (a range of the full text buffer), then moving the end by one character. When we get the document range, we get the optimized size of the buffer (the position of the last character). Moving by one character is valid because the buffer still has more to explore. We then crash from checking if the new position is valid on the **optimized size**, not the **real size**. REFERENCES #6986 - follow up to properly handle/test this "end of buffer" problem Closes #6402 (cherry picked from commit c390b61)
That's the aim of #6986. 😄 |
🎉 Handy links: |
🎉 Handy links: |
🎉 Handy links: |
Carlos Zamora (1) * UIA: use full buffer comparison in rects and endpoint setter (GH-6447) Dan Thompson (2) * Tweaks: normalize TextAttribute method names (adjective form) (GH-6951) * Fix 'bcz exclusive' typo (GH-6938) Dustin L. Howett (4) * Fix VT mouse capture issues in Terminal and conhost (GH-7166) * version: bump to 1.3 on master * Update Cascadia Code to 2007.15 (GH-6958) * Move to the TerminalDependencies NuGet feed (GH-6954) James Holderness (3) * Render the SGR "underlined" attribute in the style of the font (CC-7148) * Add support for the "crossed-out" graphic rendition attribute (CC-7143) * Refactor grid line renderers with support for more line types (CC-7107) Leonard Hecker (1) * Added til::spsc, a lock-free, single-producer/-consumer FIFO queue (CC-6751) Michael Niksa (6) * Update TAEF to 10.57.200731005-develop (GH-7164) * Skip DX invalidation if we've already scrolled an entire screen worth of height (GH-6922) * Commit attr runs less frequently by accumulating length of color run (GH-6919) * Set memory order on slow atomics (GH-6920) * Cache the viewport to make invalidation faster (GH-6918) * Correct comment in this SPSC test as a quick follow up to merge. Related work items: MSFT-28208358
In UiaTextRange,
_getBufferSize
returns an optimized version of thesize of the buffer to be the origin and the last character in the
buffer. This is to improve performance on search or checking if you are
currently on the last word/line.
When setting the endpoint and drawing the bounding rectangles, we should
be retrieving the true buffer size. This is because it is still possible
to create UiaTextRanges that are outside of this optimized size. The
main source of this is
ExpandToEnclosingUnit()
when the unit isDocument
. The end should be the last visible character, but it isn'tbecause that would break our tests.
This is an incomplete solution. #6986 is a follow up to completely test
and implement the solution.
The crash in #6402 was caused by getting the document range (a range of
the full text buffer), then moving the end by one character. When we
get the document range, we get the optimized size of the buffer (the
position of the last character). Moving by one character is valid
because the buffer still has more to explore. We then crash from
checking if the new position is valid on the optimized size, not the
real size.
REFERENCES
#6986 - follow up to properly handle/test this "end of buffer" problem
Closes #6402