## Summary of the Pull Request
Introduces convenience type `til::size` which automatically implements our best practices for size-related types and provides automatic conversions in/out of the relevant types.
## PR Checklist
* [x] In support of Differental Rendering #778
* [X] I work here.
* [x] Tests added/passed
* [x] I'm a core contributor.
## Detailed Description of the Pull Request / Additional comments
- Automatically converts in from anything with a X/Y (console `COORD`) or cx/cy (Win32 `SIZE`)
- Automatically converts out to `COORD`, `SIZE`, or `D2D1_SIZE_F`.
- Constructs from bare integers written into source file
- Default constructs to empty
- Uses Chromium Math for all basic math operations (+, -, *, /)
- Provides equality tests
- Adds initial proposal for division-to-ceiling (round up division) that attempts to `ceil` without any floating point math.
- Accessors for height/width
- Type converting accessors (that use safe conversions and throw) for height/width
- Convenience function for area calculation (as that's common with type) and uses safe math to do it.
- TAEF/WEX Output and Comparators so they will print very nicely with `VERIFY` and `Log` macros in our testing suite.
## Validation Steps Performed
- See automated tests of functionality.
## Summary of the Pull Request
- Changes the `IRenderEngine` interface to return a vector of values instead of just a single one. Engines that want to report one still can. Engines that want to report multiple smaller ones will be able to do so going forward.
## PR Checklist
* [x] In support of differential rendering #778
* [x] I work here.
* [x] Manually tested it still works.
* [x] Am core contributor.
## Detailed Description of the Pull Request / Additional comments
- Some of my ideas for the `DxEngine` require the ability to specify multiple smaller rectangles instead of one giant one, specifically to mitigate the case where someone refreshes just one cell in two opposite corners of the display (which currently coalesces into refreshing the entire display.)
- This is pulled out into an individual PR to make it easier to review that concept changing.
## Validation Steps Performed
- Ran the Terminal
With certain font faces at certain sizes, the advances seem to be
slightly more than the pixel grid; Cascadia Code at 13pt (though, 200%
scale) had an advance of 10.000001.
This commit makes it so that anything sub-1/100 of a cell won't make us
break up runs, because doing so results in suboptimal rendering.
Fixes#4806.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
I originally thought that setting `TSFInputControl::_editContext.InputPaneDisplayPolicy` to be Automatic would allow the InputPanel to show and hide automatically when `TSFInputControl` gains and loses focus. It doesn't seem to behave that way, so we'll show the InputPanel manually.
I'll show the panel during `PointerPressedHandler` and during `GotFocusHandler`. A user will have the on-screen keyboard pop up when getting focus, but if they close the keyboard, they can simply re-tap on the terminal to bring it back up.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#3639
* [x] CLA signed.
* [x] Tests added/passed
## Validation Steps Performed
Played on my surfaces book with the on screen keyboard by closing/tapping on the terminal and using the search box.
## Summary of the Pull Request
When we are maximized or fullscreened, check for the presence of the taskbar in auto-hide mode. If the Terminal finds the taskbar on any side of the monitor, adjust our window rect by just a little bit, so that the taskbar can still be revealed by the user mousing over that edge.
## References
## PR Checklist
* [x] Closes#1438
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
Note to future code archeologists:
This doesn't seem to work for fullscreen on the primary display. However, testing a bunch of other apps with fullscreen modes and an auto-hiding taskbar has shown that _none_ of them reveal the taskbar from fullscreen mode. This includes Edge, Firefox, Chrome, Sublime Text, Powerpoint - none seemed to support this.
This does however work fine for maximized.
## Validation Steps Performed
I'm maximized and fullscreened the Terminal a lot in the last two days.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Right clicking on a focused tab while Copy On Select is active currently copies any active selection. This is because `PointerReleasedHandler` doesn't check for the mouse button that was released.
During a mouse button release, only the left mouse button release should be doing anything.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4740
* [x] CLA signed.
* [x] Tests added/passed
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
These are the scenarios I've tested. They're a combination of in focus/out of focus, Copy On Select on/off, left/right click pressed and their move and release variants.
From Out of Focus:
- Left Click = Focus
- Left Click Move = Focus + Selection
- Left Click Release
- CoS on = Copy
- CoS off = Nothing
- Shift Left Click = Focus
- Right Click
- Focus
- CoS on = Paste
- CoS off = Copy if Active Selection, Paste if not.
- Right Click Move = Nothing
- Right Click Release = Nothing
From In Focus
- Left Click = Selection if CoS off
- Left Click Move = Selection
- Left Click Release
- CoS on = Copy
- CoS off = Nothing
- Shift Left Click = Set Selection Anchor
- Right Click
- CoS on = Paste
- CoS off = Copy if Active Selection, Paste if not.
- Right Click Move = Nothing
- Right Click Release = Nothing
til::color will help us move away from COLORREF internally. It supports
conversion to/from COLORREF, and from all types of structs containing
members named R, G, B and A (or r, g, b, and a).
## Validation Steps Performed
Tests; run through profile/colorScheme deserialization with `til::color`
instead of `uint32_t` or `COLORREF`.
checkpointing this since it's so close. It works for everything but fullscreen on my primary, 125% display which has the taskbar on top, and autohides. Every other case works fine.
## Summary of the Pull Request
Add a `SizeChanged` handler to the titlebar content UI element. It's possible that this element's size will change after the dragbar's. When that happens, the drag bar won't send another `SizeChanged` event, because the dragbar's _size_ didn't change, only it's position.
## References
We originally duped this issue to #4166, but after #4829 fixed that issue, this one persisted. They're all related, and _look_ like dupes, but they weren't.
## PR Checklist
* [x] Closes#4288
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
I had a solid 100% repro that doesn't repro anymore.
I've maximized, restored, resized, and generally played with the window a bunch.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Emoji composition was only being shown one letter at a time. This is because of the way I expected `CoreTextTextUpdatingEventArgs.Range` to be provided to TSFInputControl during composition (for Chinese/Japanese IME). Emoji IME composition gives the `StartCaretPosition` as the same as `EndCaretPosition`, unlike how for Chinese/Japanese IME, `StartCaretPosition` is usually the start of the composition and `EndCaretPosition` is the latest character in the composition. The solution is to change the `_inputBuffer.substr()` call to simply grab all of the buffer starting from `_activeTextStart`. This way I can ensure that I grab all of the "active text", instead of trusting the given `args.Range` to tell me the active text.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4828
* [x] CLA signed.
* [x] Tests added/passed
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Chinese, Japanese, Korean, Emoji composition performed. Emoji selection through pointer also performed.
## 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.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Translate automatically generated message text from German into English.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4799
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
@miniksa mentioned in https://github.com/microsoft/terminal/pull/4799#discussion_r389166916
> Actually..... we would consider that block to be wrong. It should have had the English error text there. [...] It's just our practice to have everything be in English as that's our company's working language. [...]
The translation is based on the message text found in the official docs: https://docs.microsoft.com/en-us/nuget/Consume-Packages/Package-restore-troubleshooting
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
## Summary of the Pull Request
We're deref'ing a null `_terminal`. Don't do that. This is a _okay_ fix, mostly to stem the bleeding. @DHowett-MSFT's got a mind for a real fix to #4166, but this isn't it.
## PR Checklist
* [x] related to #4166
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Summary of the Pull Request
Pretty straightforward. When we get a `WM_DISPLAYCHANGE`, that means the
display's DPI changed. When that happens, resize the drag bar, so that
it'll reflect the new scaling.
Unblocks #4778Closes#4166
## Validation
Man I've changed the DPI of my displays so many times in the last 30
minutes. I dragged the window across a bunch of DPI boundaries too.
AutomationProperties of interest in this PR include...
- Name: the name of a UI element (generally used as the main identifier
for it)
- HelpText: an additional description for a more complex UI element
- AccessibilityView[1]
- Raw: hide from the UIA tree. Only navigate to this if you know what
you're doing
- Control: a control without any content in it. Basically, a point at
which the user can make a decision as to how to navigate the tree or
invoke an action.
- Content: a control that also has content to present to the user.
I set a few more AutomationProperties throughout Windows Terminal...
- MinMaxClose Control: hidden (we can/should rely on the true buttons
that we are hiding)
- SplitButton: Name and Help text (currently ignored due to #4804, but
having it in the resource file won't cause any problems)
- SearchBox: added a more specific name to the close button
- BackgroundImage: hide it
## References
A few additional work items have been created for tracking...
- SplitButton: https://github.com/microsoft/terminal/issues/4804
## PR Checklist
* [X] Closes#2099
* [X] Closes#2102
## Validation Steps Performed
Verified using Accessibility Insights and Inspect.exe
[1] https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-treeoverview
## Summary of the Pull Request
Adds warning messages for a pair of keybindings-related scenarios. This covers the following two bugs:
* #4239 - If the user has supplied more than one key chord in their `"keys"` array.
* #3522 - If a keybinding has a _required_ argument, then we'll display a message to the user
- currently, the only required parameter is the `direction` parameter for both `resizePane` and `moveFocus`
## References
When we get to #1334, we'll want to remove the `TooManyKeysForChord` warning.
## PR Checklist
* [x] Closes#4239
* [x] Closes#3522
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Tested manually, added tests.
The Xaml input stack doesn't allow an application to suppress the "caret
browsing" dialog experience triggered when you press F7.
The official recommendation from the Xaml team is to catch F7 before we
hand it off.
This commit introduces a special F7 handler and an ad-hoc implementation of event bubbling.
Runtime classes implementing a custom IF7Listener interface are
considered during a modified focus parent walk to determine who can
handle F7 specifically.
If the recipient control handles F7, we suppress the message completely.
This event bubbler has some minor issues -- the search box will not be
able to receive F7 because its parent control implements the handler.
Since search is already mostly a text box, it doesn't _need_ special
caret browsing functionality as far as I can tell.
TermControl implements its OnF7Pressed handler by synthesizing a
keybindings event and an event to feed into Terminal Core directly.
It's not possible to create a synthetic KeyPressRoutedEvent; if it were,
I would have just popped one into the traditional input queue. :)
Fixes#638.
## Summary of the Pull Request
1) Improves the performance of word-recognition operations such as word
navigation in UIA and selection.
2) Fixes a bug where attempting to find the next word in UIA, when none
exists, would hang
3) TraceLogging code only runs when somebody is listening
## Detailed Description of the Pull Request / Additional comments
- The concept of a delimiter class got moved to the CharRow.
- The buffer iterator used to save a lot more information than we needed
- I missed updating a tracing function after making GetSelection return
one text range. That is fixed now.
## Validation Steps Performed
Performed Word Navigation under Narrator and NVDA.
NOTE: The release build should be used when testing to optimize
performance
Closes#4703
## Summary of the Pull Request
Korean IME was not working correctly due to way we were clearing the input buffer inside of `TSFInputControl`. We wanted to clear our input buffer and tell TSF to clear its input buffer as well when we receive a `CompositionCompleted` event. This works fine in some IME languages such as Chinese and Japanese. However, Korean IME composes characters differently in such a way where we can't tell TSF to clear their buffer during a `CompositionCompleted` event because it would clear the character that triggered the `CompositionCompleted` event in the first place.
The solution in this PR is to keep our `_inputBuffer` intact until the user presses <kbd>Enter</kbd> or <kbd>Esc</kbd>, in which case we clear our buffer and the TSF buffer. I've chosen these two keys because it seems to make sense to clear the buffer after text is sent to the terminal with <kbd>Enter</kbd>, and <kbd>Esc</kbd> usually means to cancel a current composition anyway.
This means we need to keep track of our last known "Composition Start Point", which is represented by `_activeTextStart`. Whenever we complete a composition, we'll send the portion of the input buffer between `_activeTextStart` and the end of the input buffer to the terminal. Then, we'll update `_activeTextStart` to be the end of the input buffer so that the next time we send text to the terminal, we'll only send the portion of our buffer that's "active".
## PR Checklist
* [x] Closes#4226
* [x] CLA signed
* [x] Tests added/passed
## Validation Steps Performed
Manual testing with Chinese, Japanese, and Korean IME.
* Azure: rewrite user input handler
This commit replaces the AzureConnection's input handler with one that
acts more like "getline()". Instead of the Read thread setting a state
and WriteInput filling in the right member variable, the reader blocks
on the user's input and receives it in an optional<string>.
This moves the input number parsing and error case handling closer to
the point where those inputs are used, as opposed to where they're
collected.
It also switches our input to be "line-based", which is a huge boon for
typing tenant numbers >9. This fixes#3233. A simple line editor
(supporting only backspace and CR) is included.
It also enables echo on user input, and prints it in a nice pretty green
color.
It also enables input queueing: if the user types anything before the
connection is established, it'll be sent once it is.
Fixes#3233.
* Azure: display the user's options and additional information in color
This commit colorizes parts of the AzCon's strings that include "user
options" -- things the user can type -- in yellow. This is to help with
accessibility.
The implementation here is based on a discussion with the team.
Alternative options for coloration were investigated, such as:
* Embedding escape sequences in the resource file.
This would have been confusing for translators.
The RESW file format doesn't support  escapes, so we would need
some magic post-processing.
* Embedding "markup" in the resource file (like #{93m}, ...)
This still would have been annoying for translators.
We settled on an implementation that takes resource names, colorizes
them, and string-formats them into other resources.
* Azure: follow the user's shell choice from the online portal
Fixes#2266.
* Azure: remove all credentials instead of just the first one
- don't decrement backIter ahead of the string begin
- ensure partial multibyte characters are still captured correctly if
the state class gets them byte by byte
- while we're here, switch to chromium math
Closes#4791Closes#4290
## Summary of the Pull Request
Adjusts column padding code in `CustomTextLayout` to only pad out for surrogate pairs, not anything that reports two columns.
## References
- See also #4747
## PR Checklist
* [x] Closes#4780
* [x] I work here.
* [x] Manual tests.
* [x] No doc, this fixes code to match comment. Oops.
* [x] Am core contributor. Also discussed with @leonMSFT.
## Detailed Description of the Pull Request / Additional comments
For surrogate pairs like high Unicode emoji, we receive two wchar_ts but only one column count (which is usually 2 because emoji are usually inscribed in the full-width squares.) To compensate for this, I added in a little padding function at the top of the `CustomTextLayout` construction that adds a column of 0 aligned with the second half of a surrogate pair so the text-to-glyph mapping lines up correctly.
Unfortunately, I made a mistake while either responding to PR feedback in #4747 or in the first place and I made it pad out extra 0 columns based on the FIRST column count, not based on whether or not there is a trailing surrogate pair. The correct thing to do is to pad it out based on the LENGTH of text associated with the given column count. This means that full width characters which can be represented in one wchar_t, like those coming from the IME in most cases (U+5C41 for example) will have a column count of 2. This is perfectly correct for mapping text-to-glyphs and doesn't need a 0 added after it. A house emoji (U+1F3E0) comes in as two wchar_ts (0xD83C 0xDFE0) with the column count of 2. To ensure that the arrays are aligned, the 2 matches up with the 0xD83C but the 0xDFE0 needs a 0 on it so it will be skipped over. (Don't worry, because it's a surrogate, it's naturally consumed correctly by the glyph mapper.)
The effect was that every OTHER character inserted by the IME was scaled to 0 size (as an advance of 0 was expected for 0 columns).
The fix restores it so those characters don't have an associated count and aren't scaled.
## Validation Steps Performed
- Opened it up
- Put in the house emoji like #4747 (U+1f3e0)
- Put in some characters with simplified Chinese IME (fixed now)
- Put in the utf83.txt sample text used in #4747
## Summary of the Pull Request
Match conhost behavior and clear selection on viewport/font resize.
## PR Checklist
* [X] Closes#1165
## Validation Steps Performed
Retried attached bug repro steps
## Summary of the Pull Request
- Improves the correction of the scaling and spacing that is applied to
glyphs if they are too large or too small for the number of columns that
the text buffer is expecting
## References
- Supersedes #4438
Co-authored-by: Mili (Yi) Zhang <milizhang@gmail.com>
- Related to #4704 (#4731)
## PR Checklist
* [x] Closes#696
* [x] Closes#4375
* [x] Closes#4708
* [x] Closes a crash that @DHowett-MSFT complained about with
`"x" * ($Host.UI.RawUI.BufferSize.Width - 1) + "`u{241b}"`
* [x] Eliminates an exception getting thrown with the U+1F3E0 emoji in
`_CorrectGlyphRun`
* [x] Corrects several graphical issues that occurred after #4731 was
merged to master (weird repeats and splits of runs)
* [x] I work here.
* [x] Tested manually versus given scenarios.
* [x] Documentation written into comments in the code.
* [x] I'm a core contributor.
## Detailed Description of the Pull Request / Additional comments
- The `_CorrectGlyphRun` function now walks through and uses the
`_glyphClusters` map to determine the text span and glyph span for each
cluster so it can be considered as a single unit for scaling.
- The total number of columns expected across the entire cluster
text/glyph unit is considered for the available spacing for drawing
- The total glyph advances are summed to see how much space they will
take
- If more space than necessary to draw, all glyphs in the cluster are
offset into the center and the extra space is padded onto the advance of
the last glyph in the range.
- If less space than necessary to draw, the entire cluster is marked for
shrinking as a single unit by providing the initial text index and
length (that is back-mapped out of the glyph run) up to the parent
function so it can use the `_SetCurrentRun` and `_SplitCurrentRun`
existing functions (which operate on text) to split the run into pieces
and only scale the one glyph cluster, not things next to it as well.
- The scale factor chosen for shrinking is now based on the proportion
of the advances instead of going through some font math wizardry
- The parent that calls the run splitting functions now checks to not
attempt to split off text after the cluster if it's already at the end.
This was @DHowett-MSFT's crash.
- The split run function has been corrected to fix the `glyphStart`
position of the back half (it failed to `+=` instead of `=` which
resulted in duplicated text, sometimes).
- Surrogate pair emoji were not allocating an appropriate number of
`_textClusterColumns`. The constructor has been updated such that the
trailing half of surrogate pairs gets a 0 column width (as the lead is
marked appropriately by the `GetColumns()` function). This was the
exception thrown.
- The `_glyphScaleCorrections` array stored up over the calls to
`_CorrectGlyphRun` now uses a struct `ScaleCorrection` as we're up to 3
values.
- The `ScaleCorrection` values are named to clearly indicate they're in
relation to the original text span, not the glyph spans.
- The values that are used to construct `ScaleCorrection`s within
`_CorrectGlyphRun` have been double checked and corrected to not
accidentally use glyph index/counts when text index/counts are what's
required.
## Validation Steps Performed
- Tested the utf82.txt file from one of the linked bugs. Looked
specifically at Burmese through Thai to ensure restoration (for the most
part) of the behavior
- Ensured that U+1f3e0 emoji (🏠) continues to draw correctly
- Checked Fixedsys Excelsior font to ensure it's not shrinking the line
with its ligatures
- Checked ligatureness of Cascadia Code font
- Checked combining characters U+0300-U+0304 with a capital A
PR #4548 inadvertantly broke mouse button input in the WPF control. This happened due to the extra layer of HWND indirection. The fix is to move the mouse button handling down into the native control where the window messages are now being sent.
- 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#4465Closes#4547
Defines the following automation properties for a Terminal Control:
- [**Orientation**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.getorientationcore):
- The orientation of the control
- None --> Vertical
- [**Name**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.getnamecore):
- The name as used by assistive technology and other Microsoft UI
Automation clients. Generally presented by automation clients as the
primary way to identify an element (along with the control type)
- "" --> <profile name>
- [**HelpText**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.gethelptextcore):
- The help text. Generally presented by automation clients if
requested by the user. This would be something that you would normally
expect to appear from tooltips.
- "" --> <tab title>
- [**LiveSetting**](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.getlivesettingcore):
- reports the live setting notification behavior. A representation of
how assertive this control should be when content changes.
- none --> Polite
## Detailed Description of the Pull Request / Additional comments
ProfileName had to be added to the TerminalSettings (IControlSettings)
to pass that information along to the automation peer. In the rare event
that somebody purposefully decided to make their ProfileName empty, we
fallback to the tab title.
## Validation Steps Performed
Verified using Accessibility Insights and inspect.exe
This is are some examples of the information a general user can expect
to receive about a Terminal Control.
- Type: Terminal Control
- Name: Command Prompt
- Help Text (if requested): Command Prompt - ping bing.com
- Type: Terminal Control
- Name: Ubuntu
- Help Text (if requested): cazamor@PC-cazamor:/mnt/c/Users/cazamor$
Note, it is generally read by an automation client as follows:
"<type>, <name>"
References #2099 - Automation Properties for TerminalControl, Search Box
References #2142 - Localization
Closes#2142
## Summary of the Pull Request
`keys` in `keybindings` now accepts a string value. This assumes that you wanted a keychord of size 1. The schema and user docs were properly updated too.
This means that the following keybinding is now accepted in your profiles.json:
```json
{ "command": "copy", "keys": "ctrl+c" }
```
as opposed to...
```json
{ "command": "copy", "keys": [ "ctrl+c" ] }
```
## PR Checklist
* [X] Closes#4713
* [X] CLA signed.
* [X] Tests added/passed
* [X] Requires documentation to be updated
## Validation Steps Performed
- [X] tested the new schema
- [X] added test
## Summary of the Pull Request
Fix a bug where the `Renderer::PaintFrame` method:
1. is not called until the next `RenderThread::NotifyThread` call but needs to be called because there the terminal was updated (theoretical bug)
2. is called twice but needs to be called only once (verified bug)
## References
The bug was introduced by #3511.
## PR Checklist
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Detailed Description of the Pull Request / Additional comments
### Before
#### First bug
In the original code, `_fNextFrameRequested` is set to `true` in render thread because `std::atomic_flag::test_and_set` is called.
This is wrong because it means that the render thread will render the terminal again even if there is no change after the last render.
I think the the goal was to load the boolean value for `_fNextFrameRequested` to check whether the thread should sleep or not.
The problem is that there is no method on `std::atomic_flag` to load its boolean value. I guess what happened was that the "solution" that was found was to use `std::atomic_flag::test_and_set`, followed by `std::atomic_flag::clear` if the value was `false` originally (if `std::atomic_flag::test_and_set` returned `false`) to restore the original value. I guess that this was believed to be equivalent to just a simple load, without doing any change to the value because it restores it at the end.
But it's not: this is dangerous because if the value is changed to `true` between the call to `std::atomic_flag::test_and_set` and the call to `std::atomic_flag::clear`, then the value ends up being `false` at the end which is wrong because we don't want to change it! And if that value ends up being `false`, it means that we miss a render because we will wait on `_hEvent` during the next iteration on the render thread.
Well actually, here, this not even a problem because when that code is ran, `_fPainting` is `false` which means that the other thread that modifies the `_fNextFrameRequested` value through `RenderThread::NotifyPaint` will not actually modify `_fNextFrameRequested` but rather call `SetEvent` (see the method's body).
But wait! There is a problem there too! `std::atomic_flag::test_and_set` is called for `_fPainting` which sets its value to `true`. It was probably unintended. So actually, the next call to `RenderThread::NotifyPaint` _will_ end up modifying `_fNextFrameRequested` which means that the data race I was talking about _might_ happen!
#### Second bug
Let's go back a little bit in my explanation. I was talking about the fact that:
> I guess what happened was that the "solution" that was found was to use `std::atomic_flag::test_and_set`, followed by `std::atomic_flag::clear` if the value was `false` originally (if `std::atomic_flag::test_and_set` returned `false`) to restore the original value.
The problem is that the reverse was done in the implementation: `std::atomic_flag::clear` is called if the value was _`true`_ originally!
So at this point, if the value of `_fNextFrameRequested` was `false`, then `std::atomic_flag::test_and_set` sets its is set to `true` and returns `false`. So for the next iteration, `_fNextFrameRequested` is `true` and the render thread will re-render but that was not needed.
### After
I used `std::atomic<bool>` instead of `std::atomic_flag` for `_fNextFrameRequested` and the other atomic field because it has a `load` and a `store` method so we can actually load the value without changing it.
I also replaced `_fPainting` by `_fWaiting`, which is basically the opposite of `_fPainting` but stays `true` for a little shorter than `_fPainting` would stay `false`. Indeed, I think that it makes more sense to directly wrap/scope _just_ the call to `WaitForSingleObject` by setting my atomic variable to `true` _just_ before and to `false` _just_ after because:
* It makes more sense while you're reading the code: it's easier IMO to understand what the purpose of `_fWaiting` is (that is, to call `SetEvent` from `RenderThread::NotifyPaint` if it's `true`).
* It's probably a tiny bit better for performance because it will become `true` for a little shorter which means less calls to `SetEvent`.
#### Warning
I don't really understand [std::memory_order](https://en.cppreference.com/w/cpp/atomic/memory_order)s.
So I used the default one (`std::memory_order_seq_cst`) which is the safest.
I believe that if no read or write are reordered in the two threads (`RenderThread::NotifyPaint` and `RenderThread::_ThreadProc`), then the code I wrote will behave correctly.
I think that `std::memory_order_seq_cst` enforces that so it should be fine, but I'm not sure.
## Validation Steps Performed
**I tried to reproduce the second bug that I described in the first section of this PR.**
I put a breakpoint on `RenderThread::NotifyPaint` and on `Renderer::PaintFrame`. Initially they are disabled. Then I ran the terminal in Release mode, waited a bit for the prompt to display and the cursor to start blinking. Then I enabled the breakpoints.
### Before
Each `RenderThread::NotifyPaint` is followed by 2 `Renderer::PaintFrame` calls. ❌
### After
Each `RenderThread::NotifyPaint` is followed by 1 `Renderer::PaintFrame` call. ✔️
## Summary of the Pull Request
Changes how conpty emits text to preserve line-wrap state, and additionally adds rudimentary support to the Windows Terminal for wrapped lines.
## References
* Does _not_ fix (!) #3088, but that might be lower down in conhost. This makes wt behave like conhost, so at least there's that
* Still needs a proper deferred EOL wrap implementation in #780, which is left as a todo
* #4200 is the mega bucket with all this work
* MSFT:16485846 was the first attempt at this task, which caused the regression MSFT:18123777 so we backed it out.
* #4403 - I made sure this worked with that PR before I even sent #4403
## PR Checklist
* [x] Closes#405
* [x] Closes#3367
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
I started with the following implementation:
When conpty is about to write the last column, note that we wrapped this line here. If the next character the vt renderer is told to paint get is supposed to be at the start of the following line, then we know that the previous line had wrapped, so we _won't_ emit the usual `\r\n` here, and we'll just continue emitting text.
However, this isn't _exactly_ right - if someone fills the row _exactly_ with text, the information that's available to the vt renderer isn't enough to know for sure if this line broke or not. It is possible for the client to write a full line of text, with a `\n` at the end, to manually break the line. So, I had to also add the `lineWrapped` param to the `IRenderEngine` interface, which is about half the files in this changelist.
## Validation Steps Performed
* Ran tests
* Checked how the Windows Terminal behaves with these changes
* Made sure that conhost/inception and gnome-terminal both act as you'd expect with wrapped lines from conpty
This commit removes all of the custom UI initialization code in
TermControl and replaces it with a xaml file. Some dead or reundant code
was removed as part of this refactoring.
It also fixes two (quasi-related) issues:
* The search box, on first launch, was offset by the scrollbar even if
the scrollbar was invisible.
* The scrollbar state wasn't hot-reloadable.
The new UIA code in PublicTerminalCore broke windows 7 support by referring
to API set dlls for UIA. This PR changes the link line to link to
UIAutomationcore.dll directly.
## Summary of the Pull Request
- Surrogate pairs are being split in half with the run splitting check.
## References
- Related to #4708 but not going to fix it.
## PR Checklist
* [x] Closes#4704
* [x] I work here.
* [x] I am a core contributor.
## Detailed Description of the Pull Request / Additional comments
- The adjustment of the run heights in the correction function reports back a text index and a scaling factor. However, I didn't remember at the time that the text is being stored as UTF-16. So the index given can be pointing to the high surrogate of a pair. Thus adding 1 to split "after" the text character, then backing up by 1 isn't valid in if the index given was for a high surrogate.
The quick fix is to advance by two if it's a high surrogate and one otherwise.
## Validation Steps Performed
- Used the sample code from #4704 to print the house emoji in various situations into the buffer.
## Summary of the Pull Request
Currently, when the user attempts to type using IME while the Search Box is focused, the input goes to the terminal instead. This is due to the fact that the `TSFInputControl` assumes it's in control whenever TermControl gets focus. So, it'll intercept IME input before the Search Box receives it. We simply need to modify `TermControl::GotFocus` to check if the SearchBox has focus. If it does, `TSFInputControl::NotifyFocusEnter` shouldn't be called.
As a small side fix, I've also disabled the terminal cursor blinking when the Search Box has focus.
Thinking a little further, if we have more features in the future that behave like search box (i.e. advanced tab switcher, or any other XAML controls that pop up) and require text input, we might need to create a sort of "AnyOtherTextControlInFocus" function to see if TSFInputControl should receive focus or not.
## PR Checklist
* [x] Closes#4434
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
## Validation Steps Performed
Search works as expected with IME. Composition picker appears underneath Search Box when typing IME in the Search Box. Clicking outside of the Search Box still returns control to TSFInputControl/TermControl.
Terminal Cursor blinks when it has focus, and doesn't when the Search Box has focus.
## Summary of the Pull Request
Currently, while in IME mode, selections with the Emoji/Kaomoji/Symbol Picker (which is brought up with <kbd>win+.</kbd>) are not displayed until the user starts a new composition. This is due to the fact that we hide the TextBlock when we receive a CompositionCompleted event, and we only show the TextBlock when we receive a CompositionStarted event. Input from the picker does not count as a composition, so we were never showing the text box, even if the symbols were thrown into the inputBuffer. In addition, we weren't receiving CompositionStarted events when we expected to.
We should be showing the TextBlock when we receive _any_ text, so we should make the TextBlock visible inside of `TextUpdatingHandler`. Furthermore, some really helpful discussion in #3745 around wrapping the `NotifyTextChanged` call with a `NotifyFocusLeave` and a `NotifyFocusEnter` allowed the control to much more consistently determine when a CompositionStarted and a CompositionEnded.
I've also went around and replaced casts with saturating casts, and have removed the line that sets the `textBlock.Width()` so that it would automatically set its width. This resolves the issue where while composing a sentence, the textBlock would be too small to contain all the text, so it would be cut off, but the composition is still valid and still able to continue.
## PR Checklist
* [x] Closes#4148
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
## Validation Steps Performed
Tested picking emojis, kaomojis, and symbols with numerous different languages.
This commit introduces two fixes for C5205 (delete of an abtract class
without a virtual dtor) and one fix for a very hopeful VS version gating
that didn't pan out.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
- Scale the retro terminal effects (#3468) scan lines with the screen's DPI.
- Remove artifacts from sampling wrap around.
Before & after, with my display scale set to 350%:
Before & after showing artifact removal, with my display scale set to 100%, and image enlarged to 400%:
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4362
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
Adds a constant buffer, which could be used for other settings for the retro terminal pixel shader.
I haven't touched C++ in over a decade before this change, and this is the first time I've played with DirectX, so please assume my code isn't exactly best practice. 🙂
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- Changed display scale with experimental.retroTerminalEffect enabled, enjoyed scan lines on high resolution monitors.
- Enabled experimental.retroTerminalEffect, turned the setting off, changed display scale. Retro tabs still scale scan lines.
This PR hooks up the existing UIA implementation to the WPF control. Some existing code that was specific to the UWP terminal control could be shared so that has been refactored to a common location as well.
## Validation Steps Performed
WPF control was brought up in UISpy and the UIA tree was verified. NVDA was then used to check that screen readers were operating properly.
## Summary of the Pull Request
Fixes a flaw that happened if `til::u8u16` received a single lead byte.
## PR Checklist
* [x] Closes#4673
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
The loop for caching partials didn't run and thus, the lead byte was
converted to U+FFFD. That's because the loop starts with `sequenceLen`
initialized with 1. And if the string has a length of 1 the initial
condition is `1<1` which is evaluated to `false` and the body of the
loop was never executed.
## Validation Steps Performed
1) updated the code of the state class and tested manually that `printf
"\xE2"; printf "\x98\xBA\n"` prints a U+263A character
2) updated the unit tests to make sure that still up to 3 partials are
cached
3) updated the unit tests to make sure caching also works if the string
consists of a lead byte only
4) tested manually that #4086 is still resolved
