-
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 Providers misrepresent box selections #4509
Comments
Closed the PR attempting to fix this. Ran into the following problem: TextBuffer:
Selecting from Proposed ImplementationCreate a |
This has always been an issue and is task-level work; recategorized as a task. |
- When performing chunk selection, the expansion now occurs at the time of the selection, not the rendering of the selection - `GetSelectionRects()` was moved to the `TextBuffer` and is now shared between ConHost and Windows Terminal - Some of the selection variables were renamed for clarity - Selection COORDs are now in the Text Buffer coordinate space - Fixes an issue with Shift+Click after performing a Multi-Click Selection ## References This also contributes to... - #4509: UIA Box Selection - #2447: UIA Signaling for Selection - #1354: UIA support for Wide Glyphs Now that the expansion occurs at before render-time, the selection anchors are an accurate representation of what is selected. We just need to move `GetText` to the `TextBuffer`. Then we can have those three issues just rely on code from the text buffer. This also means ConHost gets some of this stuff for free 😀 ### TextBuffer - `GetTextRects` is the abstracted form of `GetSelectionRects` - `_ExpandTextRow` is still needed to handle wide glyphs properly ### Terminal - Rename... - `_boxSelection` --> `_blockSelection` for consistency with ConHost - `_selectionAnchor` --> `_selectionStart` for consistency with UIA - `_endSelectionPosition` --> `_selectionEnd` for consistency with UIA - Selection anchors are in Text Buffer coordinates now - Really rely on `SetSelectionEnd` to accomplish appropriate chunk selection and shift+click actions ## Validation Steps Performed - Shift+Click - Multi-Click --> Shift+Click - Chunk Selection at... - top of buffer - bottom of buffer - random region in scrollback Closes #4465 Closes #4547
## Summary of the Pull Request `GetTextForClipboard` already exists in the TextBuffer. It makes sense to use that for UIA as well. This changes the behavior or `GetText()` such that it does not remove leading/trailing whitespace anymore. That is more of an expected behavior. ## References This also contributes to... - #4509: UIA Box Selection - #2447: UIA Signaling for Selection - #1354: UIA support for Wide Glyphs Now that the expansion occurs at before render-time, the selection anchors are an accurate representation of what is selected. We just need to move GetText to the TextBuffer. Then we can have those three issues just rely on code from the text buffer. This also means ConHost gets some of this stuff for free 😀 ## Detailed Description of the Pull Request / Additional comments - `TextBuffer::GetTextForClipboard()` --> `GetText()` - `TextBuffer::GetText()` no longer requires GetForegroundColor/GetBackgroundColor. If either of these are not defined, we return a `TextAndColor` with only the `text` field populated. - renamed a few parameters for copying text to the clipboard for clarity - Updated `UiaTextRange::GetText()` to use `TextBuffer::GetText()` ## Validation Steps Performed Manual tests for UIA using accessibility insights and Windows Terminal's copy action (w/ and w/out shift) Added tests as well.
## Summary of the Pull Request Block selections were always read and displayed as line selections in UIA. This fixes that. ## PR Checklist * [x] Closes #4509 ## Detailed Description of the Pull Request / Additional comments 1. Expose `IsBlockSelection()` via IUiaData 2. Update the constructor to be able to take in a block selection parameter 3. Make ScreenInfoUiaProviders pass step 1 output into step 2 constructor 4. Update all instances of `UiaTextRange::GetTextRects()` to include this new flag ## Validation Steps Performed Manually tested. Additional tests would be redundant as GetTextRects() is tested in the text buffer.
## Summary of the Pull Request Block selections were always read and displayed as line selections in UIA. This fixes that. ## PR Checklist * [x] Closes #4509 ## Detailed Description of the Pull Request / Additional comments 1. Expose `IsBlockSelection()` via IUiaData 2. Update the constructor to be able to take in a block selection parameter 3. Make ScreenInfoUiaProviders pass step 1 output into step 2 constructor 4. Update all instances of `UiaTextRange::GetTextRects()` to include this new flag ## Validation Steps Performed Manually tested. Additional tests would be redundant as GetTextRects() is tested in the text buffer.
🎉This issue was addressed in #4991, which has now been successfully released as Handy links: |
Summary
Our TermControlUiaProvider (aka ScreenInfoUiaProvider) assumes that a retrieved selection is always a line selection.
Technical Details
ScreenInfoUiaProviderBase::GetSelection()
returns aUiaTextRange
for the endpoints of the selection (after a brief inclusive/exclusive conversion). We need two modifications here:ScreenInfoUiaProviderBase
should check if the selection is a box selection or a line selection. And should create a different branch for each of those options.UiaTextRangeBase
needs...(?) modifynot needed. How selections are made is already abstracted to the selection code, not UIA providersSelect
to make a box selection?The text was updated successfully, but these errors were encountered: