Narrator scan mode crashes terminal #6402
Assignees
Labels
Area-Accessibility
Issues related to accessibility
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Product-Terminal
The new Windows Terminal.
Resolution-Fix-Committed
Fix is checked in, but it might be 3-4 weeks until a release.
Severity-Crash
Crashes are real bad news.
Milestone
Comments
ghost
added
Needs-Triage
|
It's also worth noting that this doesn't repro using non-scan mode commands. Navigating away from the "title bar" element with Caps+left arrow instead of just up arrow does not crash the app. Some other scan mode navigation commands seem to have the same effect. If at the "title bar" element you press left arrow instead of up arrow, you are returned to the edit pane (specifically a space in the bottom right corner of the edit pane). If you then press right arrow, however, the app crashes as well. |
zadjii-msft
added
Area-Accessibility
DHowett
removed
the
Needs-Triage
ghost
pushed a commit
that referenced
this issue
Jul 20, 2020
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
ghost
added
the
Resolution-Fix-Committed
DHowett
pushed a commit
that referenced
this issue
Jul 20, 2020
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)
DHowett
pushed a commit
that referenced
this issue
Jul 20, 2020
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)
|
🎉This issue was addressed in #6447, which has now been successfully released as Handy links: |
1 similar comment
|
🎉This issue was addressed in #6447, which has now been successfully released as Handy links: |
|
🎉This issue was addressed in #6447, which has now been successfully released as Handy links: |
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Windows build number: Microsoft Windows [Version 10.0.18363.836]
Windows Terminal version (if applicable): 1.0.1401.0
Any other software?: Narrator, the version which comes with this windows build
Steps to reproduce
Expected behavior
I would expect the terminal app not to crash, and for Narrator focus to return to the edit box.
Actual behavior
The terminal app crashes.
Feedback hub link
https://aka.ms/AA8mlsm
The text was updated successfully, but these errors were encountered: