-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Narrator scan mode crashes terminal #6402
Comments
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. |
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
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)
🎉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: |
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: