Further builds on #12799. #12799 assumes that the connection is prepared to receive FocusIn/FocusOut events as input. For ConPTY we can be relatively sure of that, but that's not _technically_ correct. In the hypothetical world where the connection is not a ConPTY connection, then the other side might not be expecting those sequences.
This remedies the issue by
* ConPTY will always request focus event mode (from the terminal) when it starts up
* when a client tries to disable focus events in conpty, conpty is gonna note that internally, but never transmit that to the hosting terminal, to leave the terminal in focus event mode.
* `TerminalDispatch` and `ControlCore` are hooked up now to only send focus events when the Terminal is in focus event mode (which will be always for conpty)
* At this point, it was like, 4LOC in `terminalInput.cpp` to add support for focus events to conhost as well.
## checklist
* [x] closes#11682
* This combined with #12515 will finally close out #2988 as well, but we can do that manually.
* [x] I work here
* [ ] There aren't tests for this. There probably should be.
This commit replaces our use of `size_t` to represent VT parameters with
`int32_t`. While unsigned integers have the inherent benefit of being less
ambiguous and enjoying two's complement, our buffer coordinates use signed
integers. Since a number of VT functions need to convert their parameters
to coordinates, this commit makes the conversion easier.
The benefit of this change becomes even more apparent if one considers
that a number of places performed unsafe conversions
of their size_t parameters to int or short already.
Files that had to be modified were converted to use til
wrappers instead of COORD or SMALL_RECT wherever possible.
## References
This commit contains about 20% of the work for #4015.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
I'm mostly relying on our unit tests here. Both OpenConsole and WT appear to work fine.
#### ⚠️ _Targets #12799_ ⚠️
This is an atomic bit of code that partners with #12799. It's separated as an individual PR to keep diffs more simple.
This ensures that when a terminal tells ConPTY that it's focused, that ConPTY doesn't do the `ConsoleControl(CONSOLE_FOREGROUND` thing unless the terminal application is actually in the foreground. This prevents a trivial exploit whereby a `malicious.exe` could create a PTY, tell ConPTY it has focus (when it doesn't), then use this mechanism to launch an instance of itself into the foreground.
When the terminal tells us it's in the foreground, we're gonna look at the owner of the ConPTY window handle. If that owner has focus, then cool, this is allowed. Otherwise, we won't grant them the FG right. For this to work, the terminal just have already called `ReparentPseudoConsole`.
* built on top of #12799 and #12526
* [x] Part of #2988
* [x] Tested manually.
## Window shenanigans, part the third:
Hooks the Terminal's focus state up to the underlying ConPTY. This is LOAD BEARING for allowing windows created by console applications to bring themselves to the foreground.
We're using the [FocusIn/FocusOut](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-FocusIn_FocusOut) sequences to communicate to ConPTY when a control gains/loses focus. Theoretically, other terminals could do this as well.
## References
#11682 tracks _real_ support for this sequence in Console & conpty. When we do that, we should consider even if a client application disables this mode, the Terminal & conpty should always request this from the hosting terminal (and just ignore internally to ConPTY).
See also #12515, #12526, which are the other two parts of this effort. This was tested with all three merged together, and they worked beautifully for all our scenarios. They are kept separate for ease of review.
## PR Checklist
* [x] This is prototype 3 for #2988
* [x] I work here
* [ ] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This allows windows spawned by console processes to bring themselves to the foreground _when the console is focused_. (Historically, this is also called in the WndProc, when focus changes).
Notably, before this, ConPTY was _never_ focused, so windows could never bring themselves to the foreground when run from a ConPTY console. We're not blanket granting the SetForeground right to all console apps when run in ConPTY. It's the responsibility of the hosting terminal emulator to always tell ConPTY when a particular instance is focused.
## Validation Steps Performed
(gif below)
This will result in the deletion of the following directories from the OS tree, under `onecore/windows/core/console/open`:
* doc/
* src/tools/MonarchPeasantPackage/
* src/api-ms-win-core-synch-l1-2-0/
* src/tools/ansi-color/
* src/tools/ColorTool/
We have gotten some PoliCheck flags on `doc/` (thanks to Niksa.md), but also the OS build just doesn't need these folders 😄
#12149 introduced a bug where `ClearCommandline()` is called on any user
profile containing the non-canonical strings "cmd.exe" or "powershell.exe"
in the "commandline" field. If you happen to have set the "commandline"
field in your `profiles.defaults`, this will cause these user profiles
to adopt the base layer command-line instead of the defaults layer one.
This commit fixes the issue, by checking the command-line after the call
to `ClearCommandline()` and ensuring it's the expected string.
Additionally this moves the migration logic to `SettingsLoader` as this allows
us to write the fixed settings to disk, if any fixed had to be applied.
## PR Checklist
* [x] Closes#12842
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* The modified unit test fails without these changes ✅
* The modified unit test succeeds with these changes ✅
* Setting `profiles.defaults.commandline` to "pwsh.exe" and setting
my "...\\powershell.exe" profile to use just "powershell.exe" as
the `commandline`, doesn't cause it to use "pwsh.exe" ✅
The fixed settings are written to settings.json ✅
This is exactly the same as #12855, save for one small difference:
```diff
diff --git a/build/pipelines/ci.yml b/build/pipelines/ci.yml
index e4e53e9b2..dc9040aeb 100644
--- a/build/pipelines/ci.yml
+++ b/build/pipelines/ci.yml
@@ -99,7 +99,6 @@ stages:
- stage: CodeIndexer
displayName: Github CodeNav Indexer
dependsOn: [Build_x64]
- condition: succeeded()
+ condition: and(succeeded(), not(eq(variables['Build.Reason'], 'PullRequest')))
jobs:
- template: ./templates/codenav-indexer.yml
- condition: not(eq(variables['Build.Reason'], 'PullRequest'))
```
Because the first ones failed with an error about a duplicate condition
And that hosed the whole CI
VTE only rewraps the contents of the (normal screen + its scrollback
buffer) on a resize event. It doesn't rewrap the contents of the
alternate screen. The alternate screen is used by applications which
repaint it after a resize event. So, it doesn't really matter. However,
in that short time window, after resizing the terminal but before the
application catches up, this prevents vertical lines
It was really hard to get a gif of this where it happened and was small
enough to upload to GH, but there is one in #12719.
There's something in this branch that fixes a scrolling issue in the
parent PR. I'm partially filing this so I can look at the diffs here and
try and figure out what that is. I kinda want to just take all 3 alt
buffer PRs as a single atomic unit, but splitting them up made sense
from a review standpoint.
Closes#3493
The original research for a solution all the way back in #11032 contained an
unfortunate flaw. The nearby font loading code was written under the assumption
that Cascadia is missing in the system font collection, leading to our issues.
Adding nearby fonts last into the collection would thus ensure that we use
the system fonts whenever possible, but only have nearby fonts as a fallback.
This didn't work and we figured that we'd have to always prefer loading nearby
fonts over system fonts. #12554 tried to achieve this, but failed to change
the order in which the font set is built. In order to prefer nearby fonts
over system ones, we have to add the system font collection last.
## PR Checklist
* [x] Closes#11648
* [x] I work here
* [x] Tests added/passed
* [x] Embarrassment for my incompetence
## Validation Steps Performed
* Put Jetbrains Mono into the AppX directory of the Debug build
* Jetbrains Mono shows up in the font selector and is useable
Additionally a more complex mini-test was built:
Using FontForge I've cloned arial.ttf and removed all characters except for
the letter "0". Afterwards I've build a custom font collection the same way
we do it in Terminal, extracted a `FontFace` named "Arial" and called
`IDWriteFont::HasCharacter` for the letter "1".
Loading the system font collection first results in `TRUE` and loading it last
results in `FALSE` (since my custom arial.ttf doesn't have the letter "1").
This confirms that we need to load the system font collection last.
We discussed this with the GitHub folks. It's pretty cool.
(Rich code nav) brings editor-level navigation capabilities into
GitHub.com for C++ and C# repos
If you want to try it out, you can go to github.dev for this repo.
If you haven't used github.dev before there are two steps to get setup:
1. In the settings file you'll need to enable Rich Code Nav. If you just
search for "rich", there'll be a checkbox to enable it.
2. Refresh the page and you should see a stacked papers icon in the task
bar at the bottom. Click on that and select "Latest Index". Then one
more refresh and you should be good to go with navigation in both C#
and C++ files!
This is an attempt to simplify the `ConGetSet` interface down to the
smallest set of methods necessary to support the `AdaptDispatch` class.
The idea is that it should then be easier to implement that interface in
Windows Terminal, so we can replace the `TerminalDispatch` class with
`AdaptDispatch`.
This is a continuation of the refactoring started in #12247, and a
significant step towards #3849.
## Detailed Description of the Pull Request / Additional comments
The general idea was to give the `AdaptDispatch` class direct access to
the high-level structures on which it needs to operate. Some of these
structures are now passed in when the class is constructed (the
`Renderer`, `RenderSettings`, and `TerminalInput`), and some are exposed
as new methods in `ConGetSet` (`GetStateMachine`, `GetTextBuffer`, and
`GetViewport`).
Many of the existing `ConhostInternalGetSet` methods could easily then
be reimplemented in `AdaptDispatch`, since they were often simply
forwarding to methods in one of the above structures. Some were a little
more complicated, though, and require further explanation.
* `GetConsoleScreenBufferInfoEx`: What we were typically using this for
was to obtain the viewport, although what we really wanted was the
virtual viewport, which is now accessible via the `GetViewport`
method. This was also used to obtain the cursor position and buffer
width, which we can now get via the `GetTextBuffer` method.
* `SetConsoleScreenBufferInfoEx`: This was only really used for the
`AdaptDispatch::SetColumns` implementation (for `DECCOLM` mode), and
that could be replaced with `ResizeWindow`. This is a slight change in
behaviour (it sizes the window rather than the buffer), but neither is
technically correct for `DECCOLM`, so I think it's good enough for
now, and at least it's consistent with the other VT sizing operations.
* `SetCursorPosition`: This could mostly be replaced with direct
manipulation of the `Cursor` object (accessible via the text buffer),
although again this is a slight change in behavior. The original code
would also have made a call to `ConsoleImeResizeCompStrView` (which I
don't think is applicable to VT movement), and would potentially have
moved the viewport (not essential for now, but could later be
supported by `DECHCCM`). It also called `VtIo::SetCursorPosition` to
handle cursor inheritance, but that should only apply to
`InteractDispatch`, so I've moved that to the
`InteractDispatch::MoveCursor` method.
* `ScrollRegion`: This has been replaced by two simple helper methods in
`AdaptDispatch` which better meet the VT requirements -
`_ScrollRectVertically` and `_ScrollRectHorizontally`. Unlike the
original `ScrollRegion` implementation, these don't generate
`EVENT_CONSOLE_UPDATE_SCROLL` events (see #12656 for more details).
* `FillRegion`: This has been replaced by the `_FillRect` helper method
in `AdaptDispatch`. It differs from the original `FillRegion` in that
it takes a rect rather than a start position and length, which gives
us more flexibility for future operations.
* `ReverseLineFeed`: This has been replaced with a somewhat refactored
reimplementation in `AdaptDispatch`, mostly using the
`_ScrollRectVertically` helper described above.
* `EraseAll`: This was previously handled by
`SCREEN_INFORMATION::VtEraseAll`, but has now been entirely
reimplemented in the `AdaptDispatch::_EraseAll` method.
* `DeleteLines`/`InsertLines`/`_modifyLines`: These have been replaced
by the `_InsertDeleteLineHelper` method in `AdaptDispatch`, which
mostly relies on the `_ScrollRectVertically` helper described above.
Finally there were a few methods that weren't actually needed in the
`ConGetSet` interface:
* `MoveToBottom`: This was really just a hack to get the virtual
viewport from `GetConsoleScreenBufferInfoEx`. We may still want
something like in the future (e.g. to support `DECVCCM` or #8879), but
I don't think it's essential for now.
* `SuppressResizeRepaint`: This was only needed in `InteractDispatch`
and `PtySignalInputThread`, and they could easily access the `VtIo`
object to implement it themselves.
* `ClearBuffer`: This was only used in `PtySignalInputThread`, and that
could easily access the buffer directly via the global console
information.
* `WriteControlInput`: This was only used in `InteractDispatch`, and
that could easily be replaced with a direct call to
`HandleGenericKeyEvent`.
As part of these changes, I've also refactored some of the existing
`AdaptDispatch` code:
* `_InsertDeleteHelper` (renamed `_InsertDeleteCharacterHelper`) is now
just a straightforward call to the new `_ScrollRectHorizontally`
helper.
* `EraseInDisplay` and `EraseInLine` have been implemented as a series
of `_FillRect` calls, so `_EraseSingleLineHelper` is no longer
required.
* `_EraseScrollback` is a essentially a special form of scrolling
operation, which mostly depends on the `TextBuffer::ScrollRows`
method, and with the filling now provided by the new `_FillRect`
helper.
* There are quite a few operations now in `AdaptDispatch` that are
affected by the scrolling margins, so I've pulled out the common
margin setup into a new `_GetVerticalMargins` helper method. This also
fixes some edge cases where margins could end up out of range.
## Validation Steps Performed
There were a number of unit tests that needed to be updated to work
around functions that have now been removed, but these substitutions
were fairly straightforward for the most part.
The adapter tests were a different story, though. In that case we were
explicitly testing how operations were passed through to the `ConGetSet`
interface, but with more than half those methods now gone, a significant
rewrite was required.
I've tried to retain the crux of the original tests, but we now have to
validate the state changes on the underlying data structures, where
before that state would have been tracked in the `TestGetSet` mock. And
in some cases we were testing what happened when a method failed, but
since that scenario is no longer possible, I've simply removed those
tests.
I've also tried to manually test all the affected operations to confirm
that they're still working as expected, both in vttest as well as my own
test scripts.
Closes#12662
"Alternate scroll mode" is a neat little mode where the app wants mouse wheel events to come through as arrow keypresses instead, when in the alternate buffer. Now that we've got support for the alt buffer in the Terminal, we can support this as well.
* [x] Closes https://github.com/microsoft/terminal/issues/3321
* [x] I work here
* [ ] Tests would be nice
Tested manually with
```bash
printf "\e[?1007h" ; man ps
```
## Window shenanigans, part the first:
This PR enables terminals to tell ConPTY what the owning window for the
pseudo window should be. This allows thigs like MessageBoxes created by
console applications to work. It also enables console apps to use
`GetAncestor(GetConsoleWindow(), GA_ROOT)` to get directly at the HWND
of the Terminal (but _don't please_).
This is tested with our internal partners and seems to work for their
scenario.
See #2988, #12799, #12515, #12570.
## PR Checklist
This is 1/3 of #2988.
This PR allows the Terminal to actually use the alt buffer
appropriately. Currently, we just render the alt buffer state into the
main buffer and that is wild. It means things like `vim` will let the
user scroll up to see the previous history (which it shouldn't).
Very first thing this PR does: updates the
`{Trigger|Invalidate}Circling` methods to instead be
`{Trigger|Invalidate}Flush(bool circling)`. We need this so that when an
app requests the alt buffer in conpty, we can immediately flush the
frame before asking the Terminal side to switch to the other buffer. The
`Circling` methods was a great place to do this, but we don't actually
want to set the circled flag in VtRenderer when that happens just for a
flush.
The Terminal's implementation is a little different than conhost's.
Conhost's implementation grew organically, so I had it straight up
create an entire new screen buffer for the alt buffer. The Terminal
doesn't need all that! All we need to do is have a separate `TextBuffer`
for the alt buffer contents. This makes other parts easier as well - we
don't really need to do anything with the `_mutableViewport` in the alt
buffer, because it's always in the same place. So, we can just leave it
alone and when we come back to the main buffer, there it is. Helper
methods have been updated to account for this.
* [x] Closes#381
* [x] Closes#3492
* #3686, #3082, #3321, #3493 are all good follow-ups here.
<!-- 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
Specs for feature request "Theme-controlled color scheme switch".
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4066
This is all of course, conjecture. This crash is totally wild and makes no sense at all. But, we're hoping that this fixes it. This should also make calls to the Monarch a little easier.
You may be asking yourself - why aren't I doing this for the Peasant too? Well, because the Peasant simply doesn't crash like the monarch does. I'm not gonna touch something that's not broken _during ask mode_.
References #12774. We can close the bug if it is verified fixed.
855e136 contains a regression which breaks buffer reflow if wide surrogate
characters are present. This happens because we made use of the
`TextBufferCellIterator` whose increment operator skips 2 cells for wide
characters. This created a "misalignment" in the reflow logic which was written
for cell-wise iteration. This commit fixes the issue, by reverting back to the
previous algorithm without iterators.
Closes#12837
Closes MSFT-38904421
## Validation Steps Performed
* Run ``pwsh -noprofile -command echo "`u{D83D}`u{DE43}"``
* Resizing conhost preserves all contents ✅
* Resizing Windows Terminal doesn't crash it ✅
* Added a test covering this issue ✅
If we delete a scheme, and the next scheme we've loaded is an inbox one
that _can't_ be deleted, then we need to toss focus to something
sensible, rather than letting it fall out to the tab item.
When deleting a scheme and the next scheme _is_ deletable, this isn't an
issue, we'll already correctly focus the Delete button.
125e9c4790 focused the SelectionBackground
button, which is the _previous_ focusable control, rather than the
following one.
However, it seems even more useful for focus to ALWAYS land on the
scheme dropdown box. This forces Narrator to read the name of the newly
selected color scheme, which seemed more useful.
I'm waiting on feedback from a11y team to see if this solution is
acceptable.
* [x] Is for #11971
After switching to ControlsV2, it seems that
delay-loading a dialog causes the ContentDialog to be assigned a
Height equal to it's content size. If we DON'T assign the
ContentDialog a Row, I believe it's assigned Row 0 by default. So,
when the dialog gets opened, the dialog seemingly causes a giant
hole to appear in the body of the app.
Assigning all the dialogs to Row 2 (where the rest of the content
is) makes the "hole" appear in the same space as the rest of the
TabContent, fixing the issue.
Note that the actual content in a content dialog gets parented to
the PopupRoot, so it actually always appeared in the correct place, it's
just this weird hole that appeared in Row 0.
* [x] Closes#12775
* See also:
* #12202 was fixed by #12208
* #12447 was fixed by #12517
* [x] Tested manually
* [x] Reverts #12625
* [x] Reverts #12517
You'd think that if a key wasn't present in a ThemeDictionary, it'd fall back to the original value. You'd be wrong - if you provide a Light&dark version of a resource, but not the HighContrast version, the resource loader will fall back to the _Light_ value. Of course.
Before (left top), after (right bottom)
Closes MSFT:38264744
This is like, 2-4% of our crashes. Impossible to say for sure, but this _looks_ like it's the root cause. This is just another one of our `HandleCommandlineArgs` buckets, hopefully the last.
* [x] Hopefully should close out MSFT:38542548
* [ ] No I didn't write tests, impossible to test
* [x] it builds
Replaces all the `RadioButton` expanders with `ComboBox`es, which can have the options inline, as opposed to in the expander content. For example, here's a single commit with the changes for a single one of these settings: 745c77d03e
### Checklist
* [x] Closes#12648
* [x] Actually closes#9566 as well (by just removing all radio buttons)
* [x] I work here
* [x] Tested manually
* [x] I'd love @carlos-zamora to have an a11y pass at this, just to see if it's egregious or not.
### Before, after:
This commit fixes some formatting bugs by upgrading clang-format and ensures
that our code is again formatted the same way Visual Studio 2022 would do it.
This is a crazy idea Dustin and I had.
> we can't repro this at will. But we kinda have an idea of where the deref is. We don't know if the small patch (throw, and try again) will fix it. We're sure that the "just fall back to an isolated monarch" will work. I'd almost rather take a build testing the small patch first, to see if that works
> This might seem crazy
> in 1.12, isolated monarch. In 1.13, "small patch". In 1.14, we can wait and see
I can write more details in the morning. It's 5pm here so if we want this today, here it is.
@dhowett double check my velocity flag logic here. Should be always true for Release, and off for Dev, Preview.
* [x] closes#12774
On certain builds of Windows, when Terminal is set as the default it
will accumulate an unbounded amount of queued animations while the
screen is off and it is servicing window management for console
applications.
This results in Terminal hanging when left overnight, as it has millions
of animations to process.
The new call into TerminalThemeHelpers will tell our compositor to
automatically complete animations that are scheduled while the screen is
off.
Fixes MSFT-38506980
Before #12691, the msixbundle version was of the format YYYY.MM.DD.0.
After #12691, it became the same as the build of Terminal it contained.
This caused some trouble for _some_ systems: major version 1 is much,
much smaller than 2022.
Adding 3000 to the major version component, _only for the bundle_, gets
around this. Ugh.
Fixes#12816.
Adds the common nuget import to the Fuzz project so that it compiles.
## References
Broken in #12778, Issue identified by #12796
## Validation Steps Performed
`Host.FuzzWrapper` project builds.
## Summary of the Pull Request
Prevents the Fuzz pipeline from failing by refactoring the nuget restore pipeline steps.
## References
Broken in #12778.
## 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
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema 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
Does what it says on the tin. This is maximal BODGE.
`TeachingTip` doesn't provide an `Opened` event.
(https://github.com/microsoft/microsoft-ui-xaml/issues/1607). But we
want to focus the renamer text box when it's opened. We can't do that
immediately, the TextBox technically isn't in the visual tree yet. We
have to wait for it to get added some time after we call IsOpen. How do
we do that reliably? Usually, for this kind of thing, we'd just use a
one-off LayoutUpdated event, as a notification that the TextBox was
added to the tree. HOWEVER:
* The _first_ time this is fired, when the box is _first_ opened,
yeeting focus doesn't work on the first LayoutUpdated. It does work on
the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated
events, and focus on the second.
* On subsequent opens: We only ever get a single LayoutUpdated. Period.
But, you can successfully focus it on that LayoutUpdated.
So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If
we've had at least 2, then we can focus the text box.
We're also not using a ContentDialog for this, because in Xaml Islands a
text box in a ContentDialog won't receive _any_ keypresses. Fun!
## References
* microsoft/microsoft-ui-xaml#1607
* microsoft/microsoft-ui-xaml#6910
* microsoft/microsoft-ui-xaml#3257
* microsoft/terminal#9662
## PR Checklist
* [x] Will close out #12021, but that's an a11y bug that needs secondary
validation
* [x] Closes#11322
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Tested manually
Make a VTApiRoutines servicer that does minimal translations instead of
environmental simulation for some output methods. Remaining methods are
backed on the existing console host infrastructure (primarily input
related methods).
## PR Checklist
* [x] I work here
* [x] It's Fix-Hack-Learn quality so it's behind a feature gate so we
can keep refining it. But it's a start!
To turn this on, you will have to be in the Dev or Preview rings
(feature staged). Then add `experimental.connection.passthroughMode:
true` to a profile and on the next launch, the flags will propagate down
through the `ConptyConnection` into the underlying `Openconsole.exe`
startup and tell it to use the passthrough mode instead of the full
simulation mode.
## Validation Steps Performed
- Played with it manually in CMD.exe, it seems to work mostly.
- Played with it manually in Ubuntu WSL, it seems to work.
- Played with it manually in Powershell and it's mostly sad. It'll get
there.
Starts #1173
This script takes pull requests from a project board, cherry-picks them,
and updates the project board. It also yells at you if there are
conflicts to resolve, and generally tries to keep track of everything.
It is quite cool.
If we do not include mp:PhoneIdentity in our AppxManifest, the store
will edit our package and re-sign it for distribution. When that
happens, it creates a divergence: there are now two versions of our
package with the same name and version number, but different contents.
This breaks everything.
**THIS IS LOAD BEARING**
<!-- 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
This builds on top of #12707. As I understand it the primary motivation for using a git submodule instead of NuGet is just that it is too annoying to have to manage dozens of packages.config files and their corresponding import statements. Now that there is a single global nuget definition that is a nonissue and we can switch over.
This also updates to the latest version of WIL.
Now that the latest version of WIL is available it uses it to replace `winrt::resume_foreground` with `wil::resume_foreground`. See [492c01bb53) for a detailed explanation of the problems with `winrt::resume_foreground` and how WIL addresses them.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes#12776, Closes#12777
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Ran `git clean -fdx` to wipe my clone to be completely clean. Opened the solution in Visual Studio 2022 and build it. Used `razzle.cmd`, `b`, and `runut.cmd` to run the tests.
These changes are purely a refactoring of the build files. There should
be no difference to the compiled result or runtime behavior.
Currently there are packages.config files in lots of directories, with
those same projects referencing props/targets from packages/ with a
version string in the path. This is frustrating because version changes
or new dependencies require updating lots and lots of build files
identically. There is also the possibility of error where locations are
missed.
With these changes there is a single canonical nuget configuration that
takes effect for all of OpenConsole.sln. Updating version numbers
should be limited to a single set of global files.
The changes were done incrementally but the result is basically that
dep\nuget\packages.config serves as the global NuGet dependency list. A
pair of common build files (common.nugetversions.props and
common.nugetversions.targets) were added to contain the various imports
and error checks. There is also a special build target to ensure that
the restore happens before builds even though a given directory doesn't
have a packages.config for Visual Studio to observe.
These new *.nugetversions.* files are imported in pretty much every
vcxproj/csproj in the solution in the appropriate place to satisfy the
need for packages. There are opt-in configuration values (e.g.
`TerminalCppWinrt=true`) that must be set to opt into a given
dependency. Adding a new dependency is just a matter of adding a new
opt-in value. The ordering of include does matter, which was a
difficult challenge to realize and address.
There was also a preexisting issue in 3 test projects where
cppwinrt.props was included but not cppwinrt.targets. By consolidating
things globally that "error" was fixed, but broke the build in a way
that was very confusing. Those projects don't need the cppwinrt targets
so they were opted out of the cppwinrt build files entirely to fix the
breaks and get back to previous behavior.
There are two notable exceptions to this canonical versioning. The
first is that there are dueling XAML 2.7 dependencies. I avoided that
by leaving those as per-project package.config entries. The second is
that any projects outside of the .sln (such as the Island samples) were
not touched.
## Validation Steps Performed
The primary validation is that the solution builds without errors. That
is what I'm seeing (x64|Debug). I also ran `git clean -fdx` from the
root of the repo to wipe it to clean and then opened the solution and
was able to build successfully. The project F5 deploys and looks fine
to me with just a cursory glance. The tests also largely pass (7418
pass, 188 fail, 14 other) which is as good or better than the baseline I
established from a clean clone.
Closes#12708
In two instances, the help text for the settings UI refers to _transparency_ when we're really talking about _opacity._ This PR changes those occurences to more accurately reflect the setting being described.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#12592
Previously we would only call `SetWindowSize` and `TriggerRedrawAll` if the
viewport size in characters changed. This commit removes the limitation.
Since the if-condition limiting full redraws is now gone, this commit
moves the responsibility of limiting the calls up the call chain.
With `_refreshSizeUnderLock` now being a heavier function call
than before, some surrounding code was thus refactored.
## PR Checklist
* [x] Closes#11317
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
Test relevant for #11317:
* Print text, filling the entire window
* Move the window from a 150% scale to a 300% scale monitor
* The application works as expected ✅
Regression tests:
* Text zoom with Ctrl+Plus/Minus/0 works as before ✅
* Resizing a window works as before ✅
* No deadlocks, etc. during settings updates ✅
Changed the default value of `"trimBlockSelection"` to `true`.
* [x] Closes#12536
## Validation Steps Performed
Without editing the setting, the toggle switch was enabled by default in the settings UI.
Since RS1 (CL 3427806), gdi32 has been available on OneCoreUAP-based
editions of Windows. Therefore, we no longer need the indirect call to
TranslateCharsetInfo and without that, IInputServices doesn't have a
reason to exist.
In an ideal world.
Unfortunately, we actually do use IInputServices as a backhanded way to
get at the ConIoSrvComm from other OneCoreInteractivity components...
we also use it in a trick we play in RundownAndExit to make sure that
the ConIoSrv connection tears down at the right time.
I've replaced that trick with an equally dirty trick, but one that is
*very explicit* about what it's doing.
This change would break CJK+Grid Lines and GetConsoleLangID on
OneCore-based editions that do not host the extension apiset
ext-ms-win-gdi-font-l1... so we're falling back to the old ConIoSrvComm
implementation directly in `dbcs.cpp`.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 74ca635710701c45cda9eefd13dafc6f180feb49
Related work items: MSFT-38632962
5964060 contains a regression were the grayscale blending algorithm used the
gamma corrected foreground color as the pixel color, instead of blending that
color with the background color first. Due to that the background color
got lost / got set to black. This breaks any dark-on-bright outputs.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
All 3 "antialiasing" settings work just like in DxEngine. ✅
## Summary of the Pull Request
Fixes a bug in ConHost where Narrator wouldn't read the deleted letter after the user pressed backspace.
## References
MSFT:31748387
## Detailed Description of the Pull Request / Additional comments
`WriteCharsLegacy()` already calls `NotifyAccessibilityEventing()` when text is inserted into the buffer ([see code](855e1360c0/src/host/_stream.cpp (L559-L563))). However, when backspace is pressed, the entire if-condition is skipped over, resulting in the accessibility event not being fired. `WriteCharsLegacy()` has a separate branch that is dedicated to handling backspace, so I added a call to the relevant logic to notify UIA at the end of that.
## Validation Steps Performed
✅ <kbd>Backspace</kbd> deletes a character and Narrator reads it
✅ <kbd>Backspace</kbd> still works with NVDA and JAWS (unchanged behavior)
✅ if the input buffer had wrapped text, the above scenario works as expected
✅ scenario works for CMD, PowerShell Core, and WSL
PR #12722 introduced a dependency on usp10.dll. The Script* APIs are split
between gdi32 and usp10, so we needed to add a new entry to the sources
files for anybody who consumed the GDI renderer.
## Summary of the Pull Request
Fixes a bug in ConHost where Narrator wouldn't read the deleted letter after the user pressed backspace.
## References
MSFT:31748387
## Detailed Description of the Pull Request / Additional comments
`WriteCharsLegacy()` already calls `NotifyAccessibilityEventing()` when text is inserted into the buffer ([see code](855e1360c0/src/host/_stream.cpp (L559-L563))). However, when backspace is pressed, the entire if-condition is skipped over, resulting in the accessibility event not being fired. `WriteCharsLegacy()` has a separate branch that is dedicated to handling backspace, so I added a call to the relevant logic to notify UIA at the end of that.
## Validation Steps Performed
✅ <kbd>Backspace</kbd> deletes a character and Narrator reads it
✅ <kbd>Backspace</kbd> still works with NVDA and JAWS (unchanged behavior)
✅ if the input buffer had wrapped text, the above scenario works as expected
✅ scenario works for CMD, PowerShell Core, and WSL
Some applications like `vim -H` implement their own BiDi reordering.
Previously we used `PolyTextOutW` which supported such arrangements,
but with a0527a1 and the switch to `ExtTextOutW` we broke such applications.
This commit restores the old behavior by reimplementing the basics
of `ExtTextOutW`'s internal workings while enforcing LTR ordering.
## Validation Steps Performed
* Create a text file with "ץחסק פחופפסנ חס קוח ז׳חסש ץקקטק פחטסץ"
Viewing the text file with `vim -H` presents the contents as expected ✅
* Printing enwik8 is as fast as before ✅
* Font fallback for various eastern scripts in enwik8 works as expected ✅
* `DECDWL` double-width sequences ✅
* Horizontal scrolling (apart from producing expected artifacts) ✅Closes#12294
(cherry picked from commit d97d9f0fcf)
The legacy console used to use case-sensitive history deduplication and
this change reverts the logic to restore ye olde history functionality.
This commit additionally changes the other remaining `std::equal` plus
`std::towlower` check into a `CompareStringOrdinal` call,
just because that's what MSDN suggests to use in such situations.
## PR Checklist
* [x] Closes#4186
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Enter `test /v`
* Enter `test /V`
* Browsing through the history yields both items ✅
(cherry picked from commit 6bc2b4af09)
`WideCharToMultiByte` doesn't write a final null-byte by default.
`til::u16u8` avoids the problem.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Test passes in Debug builds ✅
(cherry picked from commit 5072ee640f)
This removes one source of potential integer overflows from the Viewport class.
Other parts were left untouched, as this entire class of overflow issues gets
fixed all at once, as soon as we replace COORD with til::coord (etc.).
## PR Checklist
* [x] Closes#5271
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Call `ScrollConsoleScreenBufferW` with out of bounds coordinates
* Doesn't crash ✅
(cherry picked from commit a4a6dfcc8d)
As noted in #6759:
> `RtlCreateUnicodeString` creates a copy of the string on the process heap and the `PortName` variable has local-scope. The string doesn't get freed with `RtlFreeUnicodeString` before the function returns creating a memory leak.
> `CIS_ALPC_PORT_NAME` is a constant string and the `PortName` variable should instead be initialized using the `RTL_CONSTANT_STRING` macro:
>
> ```c++
> static UNICODE_STRING PortName = RTL_CONSTANT_STRING(CIS_ALPC_PORT_NAME);
> ```
I actually built this in the OS repo to make sure it'll still build, because this code doesn't even build outside Windows.
* [x] Closes#6759
* I work here.
(cherry picked from commit 349b76795f)
This adds some validation in the `UiaTextRange` ctor for the cursor position.
#8730 was caused by creating a `UiaTextRange` at the cursor position when it was in a delayed state (meaning it's purposefully hanging off of the right edge of the buffer). Normally, `Cursor` maintains a flag to keep track of when that occurs, but Windows Terminal isn't maintaining that properly in `Terminal::WriteBuffer`.
The _correct_ approach would be to fix `WriteBuffer` then leverage that flag for validation in `UiaTextRange`. However, messing with `WriteBuffer` is a little too risky for our comfort right now. So we'll do the second half of that by checking if the cursor position is valid. Since the cursor is really only expected to be out of bounds when it's in that delayed state, we get the same result (just maybe a tad slower than simply checking a flag).
Closes#8730
Filed #12440 to track changes in `Terminal::_WriteBuffer` for delayed EOL wrap.
## Validation Steps Performed
While using magnifier, input/delete wrapped text in input buffer.
(cherry picked from commit 5dcf5262b4)
This commit fixes an issue, where we failed to emit a DECTCEM sequence to hide
the cursor if it was hidden before XtermEngine's first frame was finalized.
Even in such cases we need to emit a DECTCEM sequence
in order to ensure we're in a consistent state.
## Validation Steps Performed
* Added test✅
* Run #12401's repro steps around 30 times✅Closes#12401
(cherry picked from commit dbb70778d4)
The pull request fixes the issue where "sizeof" parameter was use instead of "ARRAYSIZE".
## PR Checklist
* [x] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] 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
## Detailed Description of the Pull Request / Additional comments
This was a pretty straight forward issue, i just replace sizeof which gives the byte size with ARRAYSIZE which give the number of elements in the array.
(cherry picked from commit 5fa1ba8dab)
In !1806141, MapVirtualKey and VkKeyScan became part of OneCore (yeah,
in 2018!). GetKeyState I can't quite figure out... but it looks like
the places we would use it (Win32 Window and Selection) already either
don't exist (window) or don't work (selection) in OneCore conhost.
Removing these redirects reduces our maintenance burden quite a bit.
Because we had to run all keyboard code through the service locator,
anything that had a dependency on key translation needed to link the
entire console host. Therefore, for anything that conhost depended upon,
so did the unit test binaries. Ugh.
I chose to keep TranslateCharsetInfo, even though it looks like gdi32 is
hosted in OneCore and the code appears as though it would work. It was
not in my critical path, and is a very basic local lookup that only powers
whether gridlines are available and the console's "Lang ID".
TEST RESULTS FROM ONECORE
Microsoft.Console.Host.FeatureTests.dll
Summary: Total=408, Passed=140, Failed=266, Blocked=0, Not Run=0, Skipped=2
I do not know how to make sure that the feature tests run properly on
OneCore. It looks like ModuleSetup is failing, which is unlikely to be
related to this change (especially given that conhost *does* launch.)
If I re-run the categories individually, they either pass or get marked
as skipped intentionally.
Microsoft.Console.Host.IntegrityTests.dll
Summary: Total=5, Passed=0, Failed=5, Blocked=0, Not Run=0, Skipped=0
Same.
Microsoft.Console.Interactivity.Win32.UnitTests.dll
Summary: Total=392, Passed=392, Failed=0, Blocked=0, Not Run=0, Skipped=0
Microsoft.Console.TextBuffer.UnitTests.dll
Summary: Total=27, Passed=27, Failed=0, Blocked=0, Not Run=0, Skipped=0
Microsoft.Console.Host.UIAutomationTests.dll
Summary: Total=6, Passed=0, Failed=0, Blocked=6, Not Run=0, Skipped=0
Microsoft.Console.Types.UnitTests.dll
Summary: Total=8, Passed=8, Failed=0, Blocked=0, Not Run=0, Skipped=0
Microsoft.Terminal.Til.UnitTests.dll
Summary: Total=290, Passed=290, Failed=0, Blocked=0, Not Run=0, Skipped=0
Microsoft.Console.VirtualTerminal.Parser.UnitTests.dll
Summary: Total=748, Passed=747, Failed=0, Blocked=0, Not Run=0, Skipped=1
Microsoft.Console.VirtualTerminal.Adapter.UnitTests.dll
Summary: Total=222, Passed=222, Failed=0, Blocked=0, Not Run=0, Skipped=0
Microsoft.Console.Host.UnitTests.dll
Summary: Total=5235, Passed=5222, Failed=0, Blocked=12, Not Run=0, Skipped=1
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev c4c0267e1139d8d205bc9995da7906e5b09f03db
Related work items: MSFT-38632962
Some applications like `vim -H` implement their own BiDi reordering.
Previously we used `PolyTextOutW` which supported such arrangements,
but with a0527a1 and the switch to `ExtTextOutW` we broke such applications.
This commit restores the old behavior by reimplementing the basics
of `ExtTextOutW`'s internal workings while enforcing LTR ordering.
## Validation Steps Performed
* Create a text file with "ץחסק פחופפסנ חס קוח ז׳חסש ץקקטק פחטסץ"
Viewing the text file with `vim -H` presents the contents as expected ✅
* Printing enwik8 is as fast as before ✅
* Font fallback for various eastern scripts in enwik8 works as expected ✅
* `DECDWL` double-width sequences ✅
* Horizontal scrolling (apart from producing expected artifacts) ✅Closes#12294
[Git2Git] Merged PR 7088552: Silence TVS by using %d (int) instead of %td (ptrdiff_t)
Silence TVS by using %d (int) instead of %td (ptrdiff_t)
This commit also includes an automatic sources.dep fix.
Fixes MSFT-38106841
Fixes MSFT-38106866
Related work items: #38106841, #38106866 Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 5983633fe90cccdb1165ab28935bd704414bb6f2
Related work items: #38106841, #38106866
## THE WHITE WHALE
This is a fairly naive fix for this bug. It's not terribly performant,
but neither is resize in the first place.
When the buffer gets resized, typically we only copy the text up to the
`MeasureRight` point, the last printable char in the row. Then we'd just
use the last char's attributes to fill the remainder of the row.
Instead, this PR changes how reflow behaves when it gets to the end of
the row. After we finish copying text, then manually walk through the
attributes at the end of the row, and copy them over. This ensures that
cells that just have a colored space in them get copied into the new
buffer as well, and we don't just blat the last character's attributes
into the rest of the row. We'll do a similar thing once we get to the
last printable char in the buffer, copying the remaining attributes.
This could DEFINITELY be more performant. I think this current
implementation walks the attrs _on every cell_, then appends the new
attrs to the new ATTR_ROW. That could be optimized by just using the
actual iterator. The copy after the last printable char bit is also
especially bad in this regard. That could likely be a blind copy - I
just wanted to get this into the world.
Finally, we now copy the final attributes to the correct buffer: the new
one. We used to copy them to the _old_ buffer, which we were about to
destroy.
## Validation
I'll add more gifs in the morning, not enough time to finish spinning a
release Terminal build with this tonight.
Closes#32🎉🎉🎉🎉🎉🎉🎉🎉🎉Closes#12567
The x86 Conhost UTs were failing because--when run in a specific order
(SearchTests, then SelectionInputTests)--PrepareGlobalScreenBuffer would
attempt to enable painting on a renderer that was dead and gone and
pushing up daisies.
The legacy console used to use case-sensitive history deduplication and
this change reverts the logic to restore ye olde history functionality.
This commit additionally changes the other remaining `std::equal` plus
`std::towlower` check into a `CompareStringOrdinal` call,
just because that's what MSDN suggests to use in such situations.
## PR Checklist
* [x] Closes#4186
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Enter `test /v`
* Enter `test /V`
* Browsing through the history yields both items ✅
HLSL uses 32-bit booleans, while C++ uses 8-bit ones aligned by 32-bit.
This meant that the shader was accessing uninitialized memory
forcing ClearType blending to be randomly enabled.
This regressed in commit 5964060.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* ClearType blending works ✅
* Enabling transparent backgrounds forces grayscale blending ✅
`WideCharToMultiByte` doesn't write a final null-byte by default.
`til::u16u8` avoids the problem.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Test passes in Debug builds ✅
`std::basic_string_view::substr` throws an exception if the first argument
(offset) is out of range. If UIA is running, this creates _a lot_ of exceptions
and associated log output. This trivial change takes care of that.
After this commit we only set the default fields of a profile - primarily the
name field - as late as possible, after layering has already completed.
This ensures that we pick up any modifications from fragments.
## PR Checklist
* [x] Closes#12520
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Add a fragment at
`%LocalAppData%\Microsoft\Windows Terminal\Fragments\Fragment\fragment.json`
with
`{"profiles":[{"updates":"{61c54bbd-c2c6-5271-96e7-009a87ff44bf}","name":"NewName"}]}`
* Windows PowerShell profile is created with the name "NewName" in settings.json ✅
* Drop engine support for DirectX 9.1
Practically no one has such old hardware anymore and AtlasEngine additionally
drops support for 10.0. The fallback also didn't work properly,
because the `FeatureLevels` array failed to include 9.2 and 9.3.
We'll simply fall back to WARP on all such devices.
* Optimize shaders during compilation
The two new flags increase shader performance sometimes significantly.
* Fix shader feature level flags
D3D feature level 10.0 only support 4.0 and 10.1 only 4.1 shaders.
## PR Checklist
* [x] Closes#12655
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Add `WindowsTerminal.exe` in `dxcpl.exe`
* Add a basic `experimental.pixelShaderPath`
* All forced feature levels between `9_1` and `11_1` render as expected ✅
## Summary of the Pull Request
The purpose of the `IRenderTarget` interface was to support the concept
of multiple buffers in conhost. When a text buffer needed to trigger a
redraw, the render target implementation would be responsible for
deciding whether to forward that redraw to the renderer, depending on
whether the buffer was active or not.
This PR instead introduces a flag in the `TextBuffer` class to track
whether it is active or not, and it can then simply check the flag to
decide whether it needs to trigger a redraw or not. That way it can work
with the `Renderer` directly, and we can avoid a bunch of virtual calls
for the various redraw methods.
## PR Checklist
* [x] Closes#12551
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #12551
## Detailed Description of the Pull Request / Additional comments
Anywhere that had previously been getting an `IRenderTarget` from the
`TextBuffer` class in order to trigger a redraw, will now just call the
`TriggerRedraw` method on the `TextBuffer` class itself, since that will
handle the active check which used to be the responsibility of the
render target. All the redraw methods that were in `IRenderTarget` are
now exposed in `TextBuffer` instead.
For this to work, though, the `Renderer` needed to be available before
the `TextBuffer` could be constructed, which required a change in the
conhost initialization order. In the `ConsoleInitializeConnectInfo`
function, I had to move the `Renderer` initialization up so it could be
constructed before the call to `SetUpConsole` (which initializes the
buffer). Once both are ready, the `Renderer::EnablePainting` method is
called to start the render thread.
The other catch is that the renderer used to setup its initial viewport
in the constructor, but with the new initialization order, the viewport
size would not be known at that point. I've addressed that problem by
moving the viewport initialization into the `EnablePainting` method,
since that will only be called after the buffer is setup.
## Validation Steps Performed
The changes in architecture required a number of tweaks to the unit
tests. Some were using a dummy `IRenderTarget` implementation which now
needed to be replaced with a full `Renderer` (albeit with mostly null
parameters). In the case of the scroll test, a mock `IRenderTarget` was
used to track the scroll delta, which now had to be replaced with a mock
`RenderEngine` instead.
Some tests previously relied on having just a `TextBuffer` but without a
`Renderer`, and now they require both. And tests that were constructing
the `TextBuffer` and `Renderer` themselves had to be updated to use the
new initialization order, i.e. with the renderer constructed first.
Semantically, though, the tests still essentially work the same way as
they did before, and they all still pass.
## Summary of the Pull Request
Closes#12670
Visual Studio 2022 offered to upgrade .NET Framework from an unsupported 4.5 to a supported 4.8. I let it do its thing (and undid a number of whitespace-only changes that aren't necessary). The project still builds after this. The UIA tests fail to run but I think that is preexisting and will be filing a new issue momentarily.
## PR Checklist
* [x] Closes#12670
* [x] Tests added/passed
## Validation Steps Performed
The solution compiles in VS2022 (except for #12673).
The store did not like when I uploaded two Windows Terminal packages
built on the same date, because the appxbundle version defaulted to
YYYY.MMDD.something.
There was a risk that using *this* version number will fail because it is
thousands of numbers less than "2022". We'll have to see if the store
rolls it out properly. I cannot find any documentation on how the store
rolls out *bundle* versions (it is very aware of .appx versions...).
A local test with 1.14.72x (Preview) published via the store seems to
have worked.
This commit fixes a stray exception during settings loading,
caused by a failure to obtain the app's extension catalog.
## PR Checklist
* [x] Closes#12305
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
I'm unable to replicate the issue. ❌
However an error log was provided in #12305 with which
the function causing the exception could be determined.
This regressed recently in cfaa315.
Initially I tried to migrate TestHostApp to C++/WinRT, but due to the
unbearable compile times I've reverted it back to C++/CX (>20x difference).
Unfortunately I then forgot to fix the underlying issue before submitting a PR.
## PR Checklist
* [x] Closes#12673
* [x] I work here
* [x] Tests added/passed
Many articles I read while writing this engine claimed that GPUs can't
do branches like CPUs can. One common approach to branching in GPUs is
apparently to "mask" out results, a technique called branch predication.
The GPU will simply execute all instructions in your shader linearly,
but if a branch isn't taken, it'll ignore the computation results.
This is unfortunate for our shader, since most branches we have are
only very seldomly taken. The cursor for instance is only drawn
on a single cell and underlines are seldomly used.
But apparently modern GPUs (2010s and later?) are actually entirely
capable of branching, _if_ all lanes ("pixels") processed by a
wave (""GPU core"") take the same branch.
On both my Nvidia GPU (RTX 3080) and Intel iGPU (Intel HD Graphics 530)
this change has a positive impact on power draw. Most noticeably on the
latter this reduces power draw from 900mW down to 600mW at 60 FPS.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
It seems to work fine on Intel and Nvidia GPUs.
Unfortunately I don't have a AMD GPU to test this on, but I suspect it can't be worse.
## Summary of the Pull Request
This change makes Windows Terminal raise a `RaiseNotificationEvent()` ([docs](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.raisenotificationevent?view=winrt-22000)) for new text output to the buffer.
This is intended to help Narrator identify what new output appears and reduce the workload of diffing the buffer when a `TextChanged` event occurs.
## Detailed Description of the Pull Request / Additional comments
The flow of the event occurs as follows:
- `Terminal::_WriteBuffer()`
- New text is output to the text buffer. Notify the renderer that we have new text (and what that text is).
- `Renderer::TriggerNewTextNotification()`
- Cycle through all the rendering engines and tell them to notify handle the new text output.
- None of the rendering engines _except_ `UiaEngine` has it implemented, so really we're just notifying UIA.
- `UiaEngine::NotifyNewText()`
- Concatenate any new output into a string.
- When we're done painting, tell the notification system to actually notify of new events occurring and clear any stored output text. That way, we're ready for the next renderer frame.
- `InteractivityAutomationPeer::NotifyNewOutput()` --> `TermControlAutomationPeer::NotifyNewOutput`
- NOTE: these are split because of the in-proc and out-of-proc separation of the buffer.
- Actually `RaiseNotificationEvent()` for the new text output.
Additionally, we had to handle the "local echo" problem: when a key is pressed, the character is said twice (once for the keyboard event, and again for the character being written to the buffer). To accomplish this, we did the following:
- `TermControl`:
- here, we already handle keyboard events, so I added a line saying "if we have an automation peer attached, record the keyboard event in the automation peer".
- `TermControlAutomationPeer`:
- just before the notification is dispatched, check if the string of recent keyboard events match the beginning of the string of new output. If that's the case, we can assume that the common prefix was the "local echo".
This is a fairly naive heuristic, but it's been working.
Closes the following ADO bugs:
- https://dev.azure.com/microsoft/OS/_workitems/edit/36506838
- (Probably) https://dev.azure.com/microsoft/OS/_workitems/edit/38011453
## Test cases
- [x] Base case: "echo hello"
- [x] Partial line change
- [x] Scrolling (should be unaffected)
- [x] Large output
- [x] "local echo": keyboard events read input character twice
This sure is bodgy, but it makes sense. Right now, when we delete a profile, we load in a totally new content for the new profile's settings. That one resets the scroll view and the focus, and now the "delete" button is obviously not focused.
Instead, this PR will manually re-focus the delete button of a profile page when the page is navigated to _because we deleted another profile_.
* [x] This will take care of #11971
This removes one source of potential integer overflows from the Viewport class.
Other parts were left untouched, as this entire class of overflow issues gets
fixed all at once, as soon as we replace COORD with til::coord (etc.).
## PR Checklist
* [x] Closes#5271
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Call `ScrollConsoleScreenBufferW` with out of bounds coordinates
* Doesn't crash ✅
This fixes a pair of inbox bugs, hopefully.
* MSFT:35731327
* There's a small window where a peasant is being created when a monarch is exiting. When that happens, the new peasant will try to tell itself (the new monarch) when the peasant was last activated, but because the window hasn't actually finished instantiating, the peasant doesn't yet have a LastActivatedArgs to tell the monarch about.
* MSFT:32518679 (ARM version) / MSFT:32279047 (AMD64 version)
* This one's tricky. Not totally sure this is the fix, bug assuming my hypothesis is correct, this should fix it. Regardless, this does fix a bug that was in the code.
* If the king dies right as another window is starting, right while the new window is starting to ProposeCommandline to the monarch, the monarch could die. If it does, the new window just explodes too. Not what you want.
Vaguely tested the second bug manually, by setting breakpoints in the monarch, starting a defterm, then exiting the monarch while the handoff was in process. That now creates a new window, so that's at least something. `RemotingTests::TestProposeCommandlineWithDeadMonarch` was the closest I could get to testing that.
The first bug only got an eye check. Not sure how to repro, but I figured yeet and hopefully we get it.
* [x] Closes#12624
The `bg != _r.backgroundColor` invalidation check wasn't symmetric with
us setting `_r.backgroundColor` to `bg | _api.backgroundOpaqueMixin`.
Due to this, when the `backgroundOpaqueMixin` changed,
we didn't always update the const buffer appropriately.
## PR Checklist
* [x] Closes#11773
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Enable window transparency (`backgroundOpaqueMixin == 0x00000000`)
* Maximize window (ensure we have gutters in the first place)
* Disable window transparency (`backgroundOpaqueMixin == 0xff000000`)
* Gutters are filled ✅
This commit enables `/std:c++20` for local development under VS17.
Our CIs will continue to use VS16 and C++17 for now in order to reduce
the likelihood of regressions during the current development cycle.
It's expected that we'll migrate to VS17 soon, as this
is what conhost is already being built with anyways.
## PR Checklist
* [x] Closes#12510
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Everything compiles under `/std:c++20` ✅
This regressed in 2b202ce6, which removed `ACTCTX_FLAG_RESOURCE_NAME_VALID`
during `CreateActCtxW` under the assumption that an executable only has
one manifest. conhost has two however and we need to pick the correct one.
On OpenConsole this causes the expected `ERROR_SXS_PROCESS_DEFAULT_ALREADY_SET`.
Closes MSFT:38355907
(cherry picked from commit c820af46b7)
By replacing `IDWriteFontSetBuilder2::AddFontFile` with
`IDWriteFactory5::CreateFontFileReference` and
`IDWriteFontSetBuilder1::AddFontFile` we add nearby
font loading support for Windows 10, build 15021.
This commit also fixes font fallback for AtlasEngine,
which was crashing during testing.
Finally it fixes a bug in DxEngine, where we only created a "nearby" font
collection if we couldn't find the font in the system collection. This doesn't
fix the bug, if the font is locked or broken in the system collection.
This is related to #11648.
## PR Checklist
* [x] Closes#12420
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Build a Debug version of Windows Terminal
* Put Jetbrains Mono into the writeable AppX directory
* Jetbrains Mono is present in the settings UI ✅
* DxEngine works with Jetbrains Mono ✅
* AtlasEngine works with Jetbrains Mono ✅
This regressed in 2b202ce6, which removed `ACTCTX_FLAG_RESOURCE_NAME_VALID`
during `CreateActCtxW` under the assumption that an executable only has
one manifest. conhost has two however and we need to pick the correct one.
On OpenConsole this causes the expected `ERROR_SXS_PROCESS_DEFAULT_ALREADY_SET`.
Closes MSFT:38355907
## Summary of the Pull Request
This makes it so that the settings.json backups are no longer created when the user saves their settings via the Settings UI.
Closes#11703
"Summon" was translated as a synonym for "citation" in Spanish instead
of treating it as a RPG-related word. "Show/Hide" will hopefully
allow an improved automatic translation in the future.
Closes#10691
2b202ce6 introduced a bug, where FreeProcessData was called without the console
lock being held. The previous code can be found in 40e3dea, on line 441-454.
## PR Checklist
* [x] Closes MSFT:21372705
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
None, as this fix is purely theoretic, but it matches the stack trace
and 40e3dea clearly wasn't correctly ported to strict C++ either.
## Summary of the Pull Request
Fixes RTF generation for text with Unicode characters.
## PR Checklist
* [x] Closes#12379
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema 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
## Validation Steps Performed
Added some unit tests.
Ran the following in PowerShell and copied the emitted text into WordPad.
```pwsh
echo "This is some Ascii \ {}`nLow code units: á é í ó ú `u{2b81} `u{2b82}`nHigh code units: `u{a7b5} `u{a7b7}`nSurrogates: `u{1f366} `u{1f47e} `u{1f440}"
```
2b202ce6 introduced a bug, where FreeProcessData was called without the console
lock being held. The previous code can be found in 40e3dea, on line 441-454.
## PR Checklist
* [x] Closes MSFT:21372705
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
None, as this fix is purely theoretic, but it matches the stack trace
and 40e3dea clearly wasn't correctly ported to strict C++ either.
From MSFT:36797001. Okay so this is only .22% of our crashes, but every little bit helps, right?
Turns out this is also hitting in:
* MSFT:35726322
* MSFT:34662459
and together they're a fairly hot bug.
There's a large class of bugs where we might get a callback to one of our event handlers when we call `app.Close()` in the `AppHost` dtor. This PR adds manual revokers to these events, and makes sure to revoke them BEFORE nulling out the `_window`. That will prevent callbacks during the rest of the dtor, when the `_window` is null.
This is intended to be a PR triggered build that only runs when
features.xml has been touched, to validate that the disabled features do
not cause compilation errors.
Four (4) squashed changes, with messages preserved.
## release: move symbol publication into its own phase
Right now, symbol publication happens every time we produce a final
bundle. In the future, we may be producing multiple bundles from the
same pipeline run, and we need to make sure we only do *one* symbol
publication to MSDL.
When we do that, it will be advantageous for us to have just one phase
that source-indexes and publishes all of the symbols.
## Remove Terminal's built-in copy of the VC Runtime
This removes the trick we pulled in #5661 and saves us ~550kb per arch.
Some of our dependencies still depend on the "app" versions of the
runtime libraries, so we are going to continue shipping the forwarders
in our package. Build rules have been updated to remove the non-Desktop
VCLibs dependency to slim down our package graph.
This is not a problem on Windows 11 -- it looks like it's shipped inbox.
**BREAKING CHANGE**: When launched unpackaged, Terminal now requires the
vcruntime redist to be installed.
## Prepare for toggling XAML between 2.7.0 and -prerelease on Win11
common.openconsole.props is a pretty good place to stash the XAML
version since it is included in every project (including the WAP
project (unlike the C++ build props!)).
I've gone ahead and added a "double dependency" on multiple XAML
versions. We'll toggle them with a build flag.
## Run the release pipeline twice, for Win10 and Win11, at the same time
This required some changes in how we download artifacts to make sure
that we could control which version of Windows we were processing in any
individual step.
We're also going to patch the package manifest on the Windows 11 version
so the store targets it more specifically.
On top of the prior three steps, this lets us ship a Windows 11
package that costs only ~15MB on disk. The Windows 10 version, for
comparison, is about 40.
The previous implementation only inverted the RGB values of the cell,
but failed to account for situations where the `color` is transparent,
which is the case when `backgroundOpaqueMixin` is 0 (for instance if
acrylic backgrounds are enabled). In these situations the alpha
component remained 0 which caused the cursor to be invisible.
For some inexplicable reason this issue is only visible on a HDR display,
even though it should also effect regular ones. God knows why.
With this commit the cursor texture is treated as a mask that inverts the color.
We use branching here, because I couldn't come up with a more clever solution.
## PR Checklist
* [x] Closes#12507
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Cursor is visible on a HDR display with acrylic background ✅
* TBD performance benchmark for `[branch]` ❌
Fixes two crashes amounting to 14% of our crash burden in Simulated
Selfhost. I can't reproduce this organically, but I was able to do so by
forcing the command palette to be empty.
## Summary of the Pull Request
In PR #12462, a new `maxversiontested` entry was added to the
_WindowsTerminal.manifest_ file which now gets propagated to the
_TerminalApp.Unit.Tests.manifest_ file whenever a full build is
executed. This PR is just committing the updated test manifest.
## PR Checklist
* [x] Closes#12543
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #12543
## Summary of the Pull Request
Prevents a crash that could occur when invoking `wt C:\`
## PR Checklist
* [x] Closes#12535
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema 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
## Detailed Description of the Pull Request / Additional comments
Updates `CascadiaSettings::NormalizeCommandLine()` to check that there are a suitable number of command line arguments to be concatenated together, to prevent accessing an array index in `argv` that doesn't exist.
Also prevents a test flake that could occur in `TerminalSettingsTests::CommandLineToArgvW()`, due to generating an empty command line argument.
## Validation Steps Performed
Added a test, and checked that invoking each of the command lines below behaved as expected:
```
wtd C:\ # Window pops up with [error 2147942405 (0x80070005) when launching `C:\']
wtd C:\Program Files # Window pops up with [error 2147942402 (0x80070002) when launching `C:\Program Files']
wtd cmd # cmd profile pops up
wtd C:\Program Files\Powershell\7\pwsh -WorkingDirectory C:\ # PowerShell profile pops up in C:\
wtd "C:\Program Files\Powershell\7\pwsh" -WorkingDirectory C:\ # PowerShell profile pops up in C:\
wtd . # Window pops up with [error 2147942405 (0x80070005) when launching `.']
```
## Summary of the Pull Request
Somehow, the controls v2 update caused an issue where if you as much as _load_ a content dialog when there's already one open, we get holes in the terminal window (#12447)
This commit introduces logic to `TerminalPage` to check whether there is a content dialog open before we try to load another one.
## PR Checklist
* [x] Closes#12447
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Can no longer repro #12447
"Acrylic material" is the official name as used on Microsoft Docs
and should ensure it gets properly translated in all languages.
## PR Checklist
* [x] Closes#9846
* [x] Closes MSFT:36776499
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
We originally intended to replace the strings with "acrylic transparency",
but "acrylic material" is actually the official term on Microsoft Docs.
<!-- 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
Fix typos found by codespell. Some of it in documentation and user-visible text, mostly in code comments. While I understand you might not be interested in fixing code comments, one of the reasons being extra noise in git history, kindly note that most spell checking tools do not discriminate between documentation and code comments. So it's easier to fix everything for long maintenance.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- 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
* [x] Tests added/passed
* [X] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: [#501](https://github.com/MicrosoftDocs/terminal/pull/501)
* [ ] Schema 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
I have checked and re-checked all changes.
When the dpi is changed, call `updateFont()` instead of `TriggerFontChange`, this
means that we continue to use the existing font features/axes
Closes#11287
## Summary of the Pull Request
Modifies the OneFuzz CI Job so that it attempts to read the notification config from a file rather than the command line.
## References
Potential oversight in #10431.
## 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
Noticed that the CI job was failing on main, so took a look. According to the [docs](7f7d76fa7f/docs/notifications.md (implementation)), files should be referenced using `@./` notation.
We chose to use the "ContextMenu" resource compartment when we
changed the package name to Terminal in #12264 because it was more
broadly localized than the rest of the application.
It appears as though some platform features have trouble with the
"more qualified" resource paths that #12264 required.
To fix this, we will:
1. Copy all of the ContextMenu localizations into CascadiaPackage's
resource root
2. Switch all manifest resource paths to use resources from the package
root.
Regressed in #12264Closes#12384Closes#12406 (tracked in microsoft/powertoys#16118)
As noted in #6759:
> `RtlCreateUnicodeString` creates a copy of the string on the process heap and the `PortName` variable has local-scope. The string doesn't get freed with `RtlFreeUnicodeString` before the function returns creating a memory leak.
> `CIS_ALPC_PORT_NAME` is a constant string and the `PortName` variable should instead be initialized using the `RTL_CONSTANT_STRING` macro:
>
> ```c++
> static UNICODE_STRING PortName = RTL_CONSTANT_STRING(CIS_ALPC_PORT_NAME);
> ```
I actually built this in the OS repo to make sure it'll still build, because this code doesn't even build outside Windows.
* [x] Closes#6759
* I work here.
I believe this fixes#12383, but I can't seem to find a way to set up a N SKU VM to confirm this.
* [ ] TODO: wait till the morning to finish copying the N vhd I found off the build shares, to confirm this doesn't crash on launch.
This has been a saga.
Basically, any resources in `App.xaml` aren't going to be able to reference other theme-aware resources. We can't change the theme of the app at runtime, only elements within the app. So we can't use `ApplicationPageBackgroundThemeBrush` in app.xaml, because it will ALWAYS be evaluated as the OS theme version of that brush.
* regressed in #12326
* See also #10864
* #3917 CANNOT be fixed in the same way. We're lucky here that the TabView uses a `{ThemeResource TabViewBackground}` in markup to set the bg. We're not similarly lucky with the Pane one.
* [x] closes#12356
* [x] Tested manually. You can confirm, my eyes are bleeding from the OS-wide light mode
#12348 introduced an off-by-one bug. While the `NormalizeCommandLine` loop
should exit early when there aren't at least _two_ arguments to be joined,
the final argument-append needs to happen even if just _one_ argument exists.
This commit fixes the issue and introduces changes to additionally monitor
the early loop exit, as well as the call to `ExpandEnvironmentStringsW`.
## PR Checklist
* [x] Closes#12461
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* All `TerminalSettingsTests` tests pass ✅
* use `FontFamily="{ThemeResource SymbolThemeFontFamily}"` where possible, in XAML
* use `FontFamily{ L"Segoe Fluent Icons, Segoe MDL2 Assets" }` in codebehind
Basically just a simple string replace.
* [x] This was a bullet point in #11353
* [x] Confirmed manually on my win10 PC
* see also #12438
Actually, this is the last bullet in #11353, so I'm gonna say closes#11353.
Screenshots below.
AtlasEngine enables various debug options for D2D and D3D in Debug builds.
Among those are resource leak checks, which were broken in OpenConsole
due to the unclean exit in `ServiceLocator::RundownAndExit`.
This commit fixes the issue by running the destructors
of any renderers registered in the Window class first.
## PR Checklist
* [x] Closes#12414
* [x] I work here
## Validation Steps Performed
* Set `HKEY_CURRENT_USER\Console\UseDx` to `2`
* Run `OpenConsole.exe`
* Exit
* No exceptions are thrown ✅
Now that we've figured out how to publish the public symbols to the official Microsoft download server... we may as well embed the source code linking information inside of them given that it's right here on GitHub. This attempts to run our existing source linking scripts against the public copy of the symbols.
## PR Checklist
* [x] Closes#12443
* [x] I work here
* [x] Tested manually
## Validation Steps Performed
* [x] Build with it: https://dev.azure.com/microsoft/Dart/_build/results?buildId=44930661&view=logs&j=8f802011-b567-5b81-5fa6-bce316c020ce
* [x] Point the debugger at them and see if it can find the sources
* [x] Maybe also look at them in a hex editor or whatnot and validate I can see the source paths pointing at GitHub
Updates this narrator announcement message to include the number of results it found. There are two versions:
* one for a singular result
* one for multiple results.
which should help with loc.
We're trying to get this in with the loc hotfix, so 👀 please
* [x] will take care of the last bit of #7907
verified with narrator locally.
We're now building a fully provenance, compliance, and security
validated package (vpack) through our Release pipeline. This attaches
the last phase which automates the submission into the Windows product.
It will also automatically trace back the source, commit SHA, and build
to the submission here from the Windows side.
* [x] Automates a manual activity I performed a few times recently
* [x] I work here
* [x] Ran a test of it against `release-1.12` and it worked
## Summary of the Pull Request
Followup from our discussion during team sync, the 'automatic adjustment of indistinguishable text' setting is going to be enabled for dev builds only.
## References
#12160
## 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
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Setting appears on dev build and the feature works
## Summary of the Pull Request
The only method that was really needed in the `AdaptDefault` class was
the `PrintString` method, and that could easily be moved into the
`ConGetSet` interface. That lets us get rid of the `AdaptDefault` class
altogether, simplifying the construction of the `AdaptDispatch` class,
and brings us more in line with the `TerminalDispatch` implementation.
## PR Checklist
* [x] Closes#12318
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #12318
## Detailed Description of the Pull Request / Additional comments
The `Execute` method was never used at all, so there was no problem with
losing that. But I also noticed there was an equivalent `ExecuteChar`
method in the `ITerminalApi` interface, which also wasn't being used, so
I've removed that too.
Then there was a `Print` method taking a single `wchar_t` parameter, but
that was ultimately implemented as a `PrintString` call anyway, so that
translation could easily be accomplished in the `AdaptDispatch` calling
code, the same way it's done in `TerminalDispatch`.
That left us with the `PrintString` method, which could simply be moved
into the `ConGetSet` interface, which would then more closely match the
`ITerminalApi` interface.
There was also a `GetResult` method, that returned the status of the
last `PrintString`, but that result was never actually checked anywhere.
What I've done now is make the `PrintString` method throw an exception
on failure, and that will be caught and logged in the `StateMachine`.
## Validation Steps Performed
I've started a bash shell in conhost to verify that it still works.
Since almost everything goes through `PrintString` in VT mode, it should
be obvious if something was broken.
## Summary of the Pull Request
Other than the `s_ResizeWindow` function, the `DispatchCommon` class was
just a couple of static functions indirectly calling the `ConGetSet`
interface. So by moving the `s_ResizeWindow` implementation into the
`ConhostInternalGetSet` class, we could easily replace all usage of
`DispatchCommon` with direct calls to `ConGetSet`.
## PR Checklist
* [x] Closes#12253
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #12253
## Validation Steps Performed
I've manually confirmed the resizing operations still work as expected.
The other functions are harder to test, but were trivial replacements.
Basically, some WSL distros ship fragments that replace the `commandline` with the executable for their distro (`ubuntu.exe`, etc.). We didn't expect that when we changed the `startingDirectory` for them all to `~`.
Unfortunately, `~` is really never a valid path for a process on windows, so those distros would now fail with
```
[error 2147942667 (0x8007010b) when launching `ubuntu1804.exe']
Could not access starting directory "~"
```
If we find that we were unable to mangle `~` into the user's WSL `commandline`, then we will re-evaluate that `startingDirectory` as `%USERPROFILE%`, which is at least something sensible, if albeit not what they wanted.
* regressed in #12315
* [x] Closes#12353
* [x] Tested with a (`ubuntu1804.exe`, `~`) profile - launched successfully, where 1.13 in market fails.
* [x] added tests
We absolutely cannot allow a defterm connection to
auto-elevate. Defterm doesn't work for elevated senarios in the
first place. If we try accepting the connection, the spawning an
elevated version of the Terminal with that profile... that's a
recipe for disaster. We won't ever open up a tab in this window.
* [x] Closes#12370
* [x] Tested manually, since there's not a great way to add defterm tests
This PR updates the `ITerminalApi` and `TerminalDispatch` classes to
allow exceptions to be thrown in case of errors instead of using boolean
return values.
## References
This brings the Terminal code into alignment with the `AdaptDispatch`
and `ConGetSet` changes made in PR #12247.
And while this isn't exactly a fix for #12378, it does at least stop the
app from crashing now.
## Detailed Description of the Pull Request / Additional comments
All the `TerminalDispatch` methods have had their `noexcept` specifiers
dropped, and any `try`/`catch` wrapping removed, so exceptions will now
fall through to the `StateMachine` class where they should be safely
caught and logged.
The same goes for the `ITerminalApi` interface and its implementation in
the `Terminal` class. And many of the methods in this interface have
also had their `bool` return values changed to `void`, since there is
usually not a need for error return values now.
## Validation Steps Performed
I've manually tested the `OSC 9;9` sequence described in #12378 and
confirmed that it no longer crashes.
This adds some validation in the `UiaTextRange` ctor for the cursor position.
#8730 was caused by creating a `UiaTextRange` at the cursor position when it was in a delayed state (meaning it's purposefully hanging off of the right edge of the buffer). Normally, `Cursor` maintains a flag to keep track of when that occurs, but Windows Terminal isn't maintaining that properly in `Terminal::WriteBuffer`.
The _correct_ approach would be to fix `WriteBuffer` then leverage that flag for validation in `UiaTextRange`. However, messing with `WriteBuffer` is a little too risky for our comfort right now. So we'll do the second half of that by checking if the cursor position is valid. Since the cursor is really only expected to be out of bounds when it's in that delayed state, we get the same result (just maybe a tad slower than simply checking a flag).
Closes#8730
Filed #12440 to track changes in `Terminal::_WriteBuffer` for delayed EOL wrap.
## Validation Steps Performed
While using magnifier, input/delete wrapped text in input buffer.
With the recent change to allow text boxes to be bigger, the `Browse` button that some of them have was getting cut off when the window was too narrow. This change puts the `Browse` button below the text box instead of next to it to prevent this issue.
## PR Checklist
* [x] Closes#12335
Segoe Fluent isn't available on Windows 10, and doesn't stealthily ship with WinUI. So if we manually set the font family to `"Segoe Fluent Icons"`, then that will just display boxes in Win10.
This instead uses the resource `"{ThemeResource SymbolThemeFontFamily}"` which will gracefully fall back on Win10.
See:
* https://github.com/microsoft/microsoft-ui-xaml/issues/3745, which inspired this solution.
Guess what! The backgound image icons were also manually specifying this font, so they had to get updated too. I couldn't find any other `Segoe Fluent` references in the code.
* [x] Closes#12350
* [x] Checked Windows 11 locally
* [x] Checked Win10 (screenshots incoming from other machine)
This commit fixes an issue, where we failed to emit a DECTCEM sequence to hide
the cursor if it was hidden before XtermEngine's first frame was finalized.
Even in such cases we need to emit a DECTCEM sequence
in order to ensure we're in a consistent state.
## Validation Steps Performed
* Added test✅
* Run #12401's repro steps around 30 times✅Closes#12401
The focus box around the color schemes combo box was getting cut off, this change adds a small margin to the stackpanel to allow space for the focus box
## PR Checklist
* [x] Closes#12328
I have no idea how this is even possible to hit. If this is able to be null, then we failed to load the settings in such a catastrophic way that nothing should work. However, OP's Terminal seemed to have already loaded the settings. By all accounts, doesn't make sense.
Regardless, the code here would crash if this ever is null, so we may as well catch it.
* [x] Closes#12360
* [ ] No way to verify this since it isn't even reproable on OPs machine, but it does have a lot of hits for that failure bucket (!!!)
The previous code had two bugs for:
* paths with more than 1 whitespace
The code joins the argv array by replacing null-word terminators with
whitespace. Unfortunately it always referred to the separator between
`argv[0]` and `argv[1]` for this instead of continuing to join
those between 1 and 2, etc.
* paths sharing a common prefix with another directory
`SearchPathW` returns paths that aren't necessarily paths to files.
A call to `GetFileAttributesW` was added, ensuring we only resolve file paths.
## PR Checklist
* [x] Closes#12345
* [x] I work here
* [ ] Tests added/passed
## Validation Steps Performed
* Paths with more than 1 whitespace resolve correctly ✅
* Paths with neighboring directories sharing a common prefix resolve correctly ✅
* Tests added ✅
## Summary of the Pull Request
After 'must', the verb is used without 'to'. Correct: "must" or "have to".
## PR Checklist
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Validation Steps Performed
Not required, only comment has been changed.
## Summary of the Pull Request
We no longer do anything when the rightmost breadcrumb is invoked
## PR Checklist
* [x] Closes#12325
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Tested manually, cannot repro #12325 anymore
The `x-generate` statement seems to have fallen apart somewhere and is no longer generating the valid list of languages for display. This hardcodes the list into the manifest to restore it, which is a valid option per the documentation.
We also hardcode the limited subset of languages into the Settings application because the main application supports fewer languages than we have been translated into for the shell extensions for Windows Explorer and Start Menu integration.
## PR Checklist
* [x] Closes#12351
* [x] I work here.
* [x] Manual tests below
## Validation Steps Performed
- [x] Clean built locally with `msbuild.exe openconsole.sln /p:Configuration=Release /p:Platform=x64 /p:WindowsTerminalBranding=Release /t:Terminal\CascadiaPackage /m /bl:log4.binlog` and checked that the `appxmanifest.xml` that popped out the other side contained the same languages that it used to contain.
- [x] Built in the release pipeline
- [x] Installed release and preview branded packages. Changed my machine language to Polish (pl-PL) which is not one of the fully localized languages, but is one of the limited ones. Checked the start menu and right-click menus and saw Polish text for Terminal and Terminal Preview. Checked the Settings page in our app and saw only the limited 14 language list for the application itself.
## Summary of the Pull Request
Reducing the `MinWidth` of a toggle switch means it no longer needs a negative margin to align it correctly
## 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
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Setting a different language no longer causes the toggle switch to fall out of the expander
We're investigating an issue where the build succeeded but something still got lost somewhere. If we had the binlogs, maybe we could diff and track it down faster.
## Summary of the Pull Request
This PR refactors the `ConGetSet` API, eliminating some of the bloat produced by the `DoSrvPrivateXXXX` functions, simplifying the method naming to more closely match the `ITerminalApi` interface, and making better use of exceptions for error conditions in place of boolean return values.
## References
This is another small step towards merging the `AdaptDispatch` and `TerminalDispatch` classes (#3849).
## PR Checklist
* [x] Closes#12193
* [x] Closes#12194
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #3849
## Detailed Description of the Pull Request / Additional comments
There are two main parts to this. The first step was to get rid of all the `DoSrvPrivateXXX` functions, and move their implementation directly into the `ConhostInternalGetSet` class. For the most part this was just copying and pasting the code, but I also fixed a couple of bugs where we were using the wrong output buffer (the global buffer rather than the one associated with the output handle), and got rid of some unnecessary calls to `GetActiveBuffer`.
The second part was to make better use of exceptions for error conditions. Instead of catching the exceptions at the `ConGetSet` level, we now allow them to fall through all the way to the `StateMachine`. This greatly simplifies the `AdaptDispatch` implementation since it no longer needs to check a boolean return value on every `ConGetSet` call. This also enables the getter methods to return properties directly instead of having to use a reference parameter.
## Validation Steps Performed
A number of the unit tests had to be updated to match the new API. Sometimes this just required changes to method names, but in other cases error conditions that were previously detected with boolean returns now needed to be caught as exceptions.
There were also a few direct calls to `DoSrvPrivateXXX` functions that now needed to be invoked through other means: either by generating an equivalent escape sequence, or calling a lower level API serving the same purpose.
And in the adapter tests, the mock `ConGetSet` implementation required significant refactoring to match the new interface, mostly to account for the changes in error handling.
We have to do this so that the store sees us as one thing ("Windows
Terminal") and the Start menu sees us as another ("Terminal").
The store will reject our package if the value we use for "DisplayName"
here doesn't match the store's "reserved names".
This value is *not used* by the start menu.
- The add new profile page now uses a dropdown rather than radio buttons
- Subheaders, breadcrumb bar, buttons etc are now all centralized when the window is maximized (so they all align with the expanders now)
- We no longer override the titlebar colors and instead use the xaml defaults (these still aren't great but at least we will get the fix automatically when it happens upstream)
- Breadcrumb bar no longer has a negative margin, so there's no weird overlap that happens when the window becomes small
- The number boxes for launch size and font size now use the `Inline` placement mode rather than compact, allowing modification to the number with fewer clicks
- Textboxes now have a greater max width so they can occupy more space in the expander if needed
## Summary of the Pull Request
When using a screen reader, the buttons on the "add a new profile" page were being read weirdly:
- "New empty profile" button read as "create new button button"
- "duplicate" button read as "duplicate button button"
It's generally standard to read out the text inside the button, so I did just that by reusing the existing localized resources. This also removes the redundant "button" that is said by the screen reader.
I also removed the unused `AutomationId` and unnecessary `Button.Content` tags.
#11156 can be closed upon validation by the accessibility team.
## Validation Steps Performed
✅ navigate to both buttons using Narrator; make sure it sounds right
## Summary of the Pull Request
Adds some polish around the navigators in the profile page (i.e. "appearance" and "advanced" button) by doing the following:
- use the localized resources for the pivot on the navigators
- simplify the navigators to be buttons instead of toggle buttons
Doing so has Narrator identify these as buttons rather than toggle buttons. So now Narrator won't say that the button is "off", which just makes more sense.
## Validation Steps Performed
✅ Narrator says "Advanced button" or "Appearance button" on the navigator
✅ The navigators look the same as before
Since we turned this feature on in windows, and it relies on _lying
about the contents of the registry_, Terminal needs to be in on the
joke.
This will need to be reverted and serviced if we choose not to ship like
this.
Fixes#12308
`IDWriteTextAnalyzer::GetGlyphs` is not enough to get a
`DWRITE_SHAPING_TEXT_PROPERTIES::canBreakShapingAfter`
value that works for combining diacritical marks.
This requires an additional call to `GetGlyphPlacements`.
This commit increases CPU usage for complex text by ~10%.
## PR Checklist
* [x] Closes#11925
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* ``echo "[e`u{0301}`u{0301}]"`` prints an "e" with 2 accents ✅
I added a condition to exclude some of the NuGet PGO stuff when there was no build mode, but appear to not have propagated any of it in the PGD merge job. This sets it to Optimize here so it'll go through.
## PR Checklist
* [x] Closes#12300
* [x] I work here.
* [x] It blends.
## Validation Steps Performed
* [x] Ran the PGO Instrument Phase
* [x] Ran the PGO Optimize Phase
Basically, this is the same as #12266, but for the `SearchBoxControl`. Trickily, the ControlCore is the one that knows if there were search results, but the TermControl has to be the one to announce it.
* [x] Will take care of #11973 once a11y team confirms
* [x] Tested manually with Narrator
* [x] Resolves a part of #6319, which I'm repurposing just to displaying the number of results in general.
* See also #3920
The pull request fixes the issue where "sizeof" parameter was use instead of "ARRAYSIZE".
## PR Checklist
* [x] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [x] 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
## Detailed Description of the Pull Request / Additional comments
This was a pretty straight forward issue, i just replace sizeof which gives the byte size with ARRAYSIZE which give the number of elements in the array.
## Summary of the Pull Request
This adds names to more of our focusable elements. This should be the rest of them that I missed in #11364
## References
* #9990: a11y megathread
* #11155: original version of this
## PR Checklist
* [x] Should take care of #11996 once confirmed
* [x] I work here
## Validation Steps Performed
Used Accessibility Insights to verify.
## Detailed Description of the Pull Request / Additional comments
There is one other weird bit. All the expanders that have content below the expander (not inline), show up as focusable, but don't have names. Even when I add names to them. I believe this is due to https://github.com/microsoft/microsoft-ui-xaml/issues/5820, which is fixed in https://github.com/microsoft/microsoft-ui-xaml/pull/6032, in https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.8.0-prerelease.220118001. Unfortunately, we're on a 2.7 prerelease, so we don't have that fix yet. I may see how painful moving to that is, because we're gonna get another a11y ping as soon as 1.13 ships.
I pre-emptively added names to these guys in f7ba158dc, so that the new MUX should just fix this without any thinking on our part.
Introduced in #11416
We weren't using these macros for duplicating as well, so I forgot to duplicate a couple settings. This PR switches duplicating over to using the macros as well, which shou;d reduce future bugs.
Also adds notes to which properties are intentionally omitted from these macros.
* [x] closes#12265
* [x] Verified manually that #12120 still works as expected
Sorry for combining two fixes in one PR. I can separate if need be.
* [x] Closes#12276:
- `"bellSound": null` didn't work. This one was easier, and is atomically in bcc2ca04fc. Basically, we would deserialize that as an array with a single empty string in it, which we'd try to then play. I think it's more idomatic to have that deserialized as an empty array, which correctly falls back to playing the default sound.
* [x] Closes#12258:
- This one is the majority of the rest of the PR. If you leave the MediaPlayer open, then the media keys will _affect the Terminal_. More importantly, once the bell sounds, they'd replay the bell, which is insane. So the fix is to re-create the media player when we need it. We do this per-pane for simpler lifetime tracking. I'm not worried about the overhead of creating a mediaplayer here, since we're already throttling bells.
* Originally added in #11511
* [x] Tested manually
- Use [`no.mp4`](https://www.youtube.com/watch?v=x2w9TyCv2gk) for this since that's like, 17s long
- Checked that closing panes / the terminal while a bell was playing didn't crash
- Playing a bunch of bells at once works
- closing a pane stops the bell it's playing
- once the bell stops, the media keys went back to working for Spotify
* [x] I work here
## Summary of the Pull Request
Fix various things from the recent SUI changes
- The Appearance/Advanced toggle buttons now have a max width
- We don't need `Profiles.cpp` anymore
- The `Elevate` setting is now back in the SUI
- There is no longer an alignment difference between non-expander settings and expander settings
- Expander settings no longer require hitting `Tab` twice to get to them
<!-- 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
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Summary of the Pull Request
According to https://github.com/microsoft/microsoft-ui-xaml/issues/1971, `PaneFooter` does not set the `SizeOfSet` or `PositionInSet` properties. However, `FooterMenuItems` does and works for our scenario. So we just replaced `PaneFooter` with `FooterMenuItems`.
Will handle #11154 upon verification from the accessibility team.
## Validation Steps Performed
✅ Verified using Accessibility Insights
✅ "Open Json File" button can still be invoked and keyboard navigated to as expected
There were a number of methods in the `IStateMachineEngine` interface
which controlled how the `StateMachine` interpreted escape sequences.
But essentially what it came down to was a bunch of a properties that
were always true for the `InputStateMachineEngine`, and always false for
the `OutputStateMachine` engine. To simplify the implementation, and
make things a little more efficient, I've now replaced all of those
virtual calls with a single boolean field in the `StateMachine` that is
initialised in the constructor.
I started by adding an `isEngineForInput` parameter to the constructor
to indicate the the type of engine being passed in. But to keep things
simple for callers, and I also then added a constructor without that
parameter, which could derive the value automatically based on the type
of the engine pointer.
Then in the `StateMachine` implementation, anywhere we were previously
calling `ParseControlSequenceAfterSs3`, `FlushAtEndOfString`,
`DispatchControlCharsFromEscape`, or `DispatchIntermediatesFromEscape`,
we now just reference `_isEngineForInput`. But I've also copied across
some of the original comments from those methods, to make it clear at
the point of usage why we have a difference in behavior for input and
output.
To make sure the unit tests would catch any problems, I hardcoded the
`_isEngineForInput` field to `false`, and confirmed that it broke a
bunch of input engine tests. Then I hardcoded it to `true`, and
confirmed that it broke a bunch of state machine and output engine
tests. With the `_isEngineForInput` set correctly, everything passed.
I also manually tested the various output edge cases that would be
effected by this code - C0 controls within an escape sequence, time
delays in the middle of an escape sequence, `SCS` character set
selection which requires intermediates following an escape, and a G3
single shift select which depends on `SS3`.
Closes#12254
I didn't have the tray icon enabled before I suppose, so this never got hit? Anyhow, we need to change where we look for the AppName. Otherwise we crash on launch 😨
* [x] fixes `main`
* [x] I work here
* regressed in #12264
* [x] Tested by: actually running the Terminal with this, it launched
## Summary of the Pull Request
**Note: This PR targets #11720**
Replaces our old pivot-style settings UI with a breadcrumb bar style, as per the windows 11 style guidelines. This required splitting `Profiles.xaml` into 3 separate files, `Profiles_Base.xaml` for general settings, `Profiles_Appearance.xaml` for appearance settings, `Profiles_Advanced.xaml` for advanced settings
The header in the navigation view is now a [BreadcrumbBar](https://docs.microsoft.com/en-us/windows/apps/design/controls/breadcrumbbar), which can be used to navigate back to `Profiles_Base` after moving into the advanced or appearance page (see GIF below)
<!-- 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
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
This commit fixes the following issues when ClearType rendering is enabled:
* Colored glyphs are now drawn using grayscale AA, similar to all current
browsers. This ensures proper gamma correctness during blending in our
shader, while generally making no discernable difference for legibility.
* Our ClearType shader only emits fully opaque colors, just like the official
ClearType implementation. Due to this we need to force grayscale AA if the
user specifies both ClearType and a background image, as the image would
otherwise not be visible.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Grayscale AA when drawing emojis ✅
* Grayscale AA when using a background image ✅
## Summary of the Pull Request
Updates our SUI to follow the windows 11 style guidelines. Includes updating our setting containers to follow the 'expander' style.
## PR Checklist
* [x] Closes#10631
* [x] Closes#9978
* [x] Closes#9595
* [x] Closes#11231
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Summary of the Pull Request
This fixes a bug where several settings would not show the reset button. The root cause of this issue is two fold:
1. Hooking up `CurrentXXX`
- `GETSET_BINDABLE_ENUM_SETTING` was hooked up to the **settings** model profile object instead of the **view** model profile object. Since the settings model has no `PropertyChanged` system, any changes were directly being applied to the setting, but not notifying the view model (and thus, the view, by extension) to update themselves.
- This fix required me to slightly modify the macro. Rather than using two parameters (object and function name), I used one parameter (path to getter/setter).
2. Responding to the `PropertyChanged` notifications
- Now that we're actually dispatching the `PropertyChanged` notifications, we need to actually respond to them. This behavior was defined in `Profiles::OnNavigatedTo()` in the `PropertyChanged()` handler. Funny enough, that code was still there, it just didn't do anything because it was trying to notify that `Profiles::CurrentXXX` changed. This is invalid because `CurrentXXX` got moved to `ProfileViewModel`.
- The fix here was pretty easy. Just move the property changed handler to `ProfileViewModel`'s `PropertyChanged` handler that is defined in the ctor.
## References
Bug introduced in #11877
## Validation Steps Performed
✅ Profile termination behavior
✅ Bell notification style
✅ Text antialiasing
✅ Scrollbar visibility
Turns out, this bug only repros in Controls version 2. I'm not sure why, but it didn't repro only on main. So this fix does nothing until #11720 merges.
This PR prevents us from setting properties on the paste warning dialog unless we actually need to paste. 5f9c551b7e proves that settings these properties is what would cause the bug in the first place.
I went a step further and cleaned this up a bit. This was always a little weird, having to get the `BracketedPasteEnabled` for the active control on the UI thread before we actually display the warning. In the post-#5000 future where going back to the control like this would be a x-proc hop, I figured I should just skip that entirely and plumb the `BracketedPaste` state out in the initial request.
* [x] Closes#12202
* [x] I work here
* [x] No tests, but there's not a great place for a test like this
* [x] Doesn't affect docs
See also: #12241 which would introduce #12202 on its own.
Just like the shift+click and the alt click shortcuts, now Ctrl+Click will launch a new window with that profile, elevated.
I also found that the GenerateName wasn't updated for the elevate arg, so added that. I considered adding the following to the defaults, but decided against it. It added 10 more entries to the command palette that were only separated by the `elevate: true` param, so that didn't feel valuable. Those are posted below for posterity.
* [x] closes https://github.com/microsoft/terminal/projects/5#card-50759221
* [x] Tested manually
Includes a semi-related dead code removal for the `elevated` param for `_OpenNewWindow`, which didn't end up being used, and wouldn't work as intended anyways.
This should be most of the surfaces that we really care about for displaying "Windows Terminal". There's a pile of other references in code, but I couldn't find any other resources that mention it.
I left a lot of the references to Windows Terminal throughout. Seemed like it was fine to keep calling it that in most places, just these localized strings that are going to be displayed in the Shell that should be changed.
Rough compare:
The strings were also moved to the Context Menu resources file, because that's localized into more languages.
@DHowett we may want to spin a full build to make sure this works and I didn't miss anything
* [x] Closes#12091
There are a couple places where we now bail immediately on startup, if we think the window is going to get created without any tabs. We do that to prevent a blank window from flashing on the screen when launching auto-elevate profiles. Unfortunately, those broke defterm in a particularly hard to debug way. In the defterm invocation, there actually aren't any tabs when the app completes initialization. We use the initialization to actually accept the defterm handoff. So what would happen is that the window would immediately close itself gracefully, never accepting the handoff.
In my defense, #8514, the original auto-elevated PR, predates defterm merging (906edf7) by a few months, so I totally forgot to test this when rolling it into the subsequent iterations of that PR.
* Related to:
* #7489
* #12137
* #12205
* [x] Closes#12267
* [x] I work here
* [ ] No tests on this code unfortunately
* [x] Tested manually
Includes a semi-related code fix to #10922 to make that quieter. That is perpetually noisy, and when trying to debug defterm, you've only got about 30s to do that before it bails, so the `sxe eh` breaks in there are quite annoying.
This commit extracts DirectWrite related shader code into dwrite.hlsl
and adds support for ClearType blending.
Additionally the following changes are piggybacked into this commit:
* Some incorrect code around fallback glyph sizing was removed as
this is already accomplished by `CreateTextLayout` internally
* Hot-reload failed to work with dwrite.hlsl as the `pFileName`
parameter was missing
* Legibility of the dotted underline was improved by increasing
the line gap from 1:1 to 3:1
Part of #9999.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Types are clear ✅
When we gave users the ability to configure how the `SGR 1` attribute
should be rendered, we described those options as "intense is bright"
and "intense is bold". Internally, though, we still referred to the `SGR 1`
attribute as bold. This PR renames all occurrences of "Bold" (when
referring to the `SGR 1` attribute) as "Intense", so the terminology is
more consistent now.
PR #10969 is where we decided on the wording to describe the `SGR 1`
attribute.
Specific changes include:
* `TextAttribute::IsBold` method renamed to `IsIntense`
* `TextAttribute::SetBold` method renamed to `SetIntense`
* `VtEngine::_SetBold` method renamed to `_SetIntense`
* `ExtendedAttributes::Bold` enum renamed to `Intense`
* `GraphicsOptions::BoldBright` enum renamed to `Intense`
* `GraphicsOptions::NotBoldOrFaint` enum renamed to `NotIntenseOrFaint`
* `SgrSaveRestoreStackOptions::Boldness` enum renamed to `Intense`
## Validation Steps Performed
I've checked that the code still compiles and the unit tests still run
successfully.
Closes#12252
## Summary of the Pull Request
Expands on #9582. If the command palette finds results, the screen reader says "Suggestions available".
Makes the scenario mentioned in #7907 work.
This is sufficient for various reasons:
1. According to the bug report, saying that suggestions are available is sufficient
> Screen reader should provide the results info on searching commands like 10 results found or suggestions available when there are any search results (Source: #7907)
2. This is common practice. Settings app and XAML Controls Gallery do this for their search box.
Also, the user should be able to know how many results were found by tabbing/selecting a result item. When this is done, the screen reader will use `SizeOfSet` and `PositionInSet` to announce how many results were found and which one we're currently on.
## Validation Steps Performed
Verified this behavior using Narrator.
Verified it matches the behavior of the Settings app and the XAML Controls Gallery.
This makes the scenario mentioned in #8480 work. It's maybe not as holistic a solution as we'd like, but it definitely works.
Tested both with Narrator, and using the TabView scroll handles to get tab focus into the tab row manually
* [x] Closing the _active_ tab with <kbd>Ctrl+Shift+w</kbd> works (not the `TabViewItem` that has focus, but that's how Edgium works so that seems fine)
* [x] Opening a tab with <kbd>Ctrl+Shift+t</kbd> works
* [x] Opening the cmdpal with <kbd>Ctrl+Shift+p</kbd> works
* [x] Will take care of #8480 once we get the a11y team to validate
* [x] I work here
#### Notes:
None of
```xaml
PreviewKeyDown="_KeyDownHandler"
KeyDown="_KeyDownHandler"
KeyUp="_KeyDownHandler"
```
On the TerminalPage directly seem to fire when the focus is in the `TabViewItem` or the New Tab flyout. But they fire just fine when focus is in the `TermControl`. Interesting, because you'd think that the `TermControl` would have already handled the key...
## Summary of the Pull Request
Makes `Model::DefaultTerminal` an `IStringable`, which presents it as a string, when possible. This enables text search for defterm's setting. This also enables screen readers to identify the combo box items by their text content (app name, author, and version) as opposed to being treated as an item containing more text. As a part of that, I cleaned up the UIA tree to treat the item's name as "\<name\>, \<author\>, \<version\>". This is consistent with how the Settings App presents installed apps in Apps > Installed apps.
#11251 will be resolved upon verification by the accessibility team.
## Validation Steps Performed
Verified using Narrator and Accessibility Insights.
The PGO helpers NuGet had the Y2K22 bug. This receives and integrates the updated package in our project to restore NuGet functionality.
## PR Checklist
* [x] Closes#12261
* [x] I work here
* [x] If it builds it sits.
## Validation Steps Performed
* [x] Build new PGO instrument data with this pipeline update: https://dev.azure.com/microsoft/Dart/_build/results?buildId=44304850&view=results
More fallout from the settings refactor. Probably because testing on a Windows
10 device is hard, because you actually need a physical machine to get acrylic
to behave correctly.
Basically, the code is simpler now, but we missed the windows 10 only edge case
where acrylic can get turned on, but we forget to enable the acrylic brush, so
it just stays off.
Refer to #11619 where this regressed, and #11643, #12229, because this is just a
hard problem apparently
* [x] Closes#11743. Technically OP is complaining about behavior that's
by-design, but it made me realize this regressed in 1.12.
* [ ] No tests on this part of the `TermControl` unfortunately.
* [x] Hauled out my old Win10 laptop to verify that opacity works right:
- [x] A fresh profile isn't created with any opacity
- [x] Mouse wheeling turns on acrylic
- [x] Using `opacity` only in the settings still stealthily enables acrylic
This will turn the feature on always from this point on. That means 1.13 Stble
would be the first Stable release to have this feature (unless we cherry-pick
this to 1.12 stable, which we may)
* [x] Closes#12220
* [x] I work here
Manifest validation won't accept migration/initialization of HKCU-based registry keys anymore. The enforcement scripts says that they should be defined in code instead. So here it is: defined in code insteead.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 67c720b628de4acefbc381891b7e7d29d387038e
Related work items: MSFT-37867666
[Git2Git] Merged PR 6881093: BUILD FIX: Reintroduce BOM to conhost manifests
Related work items: MSFT-37882151
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev b6f388b08b0b431ffc5663fe27eef260688febd6
I can find the commit where this regressed tomorrow if needed. In #10685 we stopped emitting these notifications while we were deferring cursor drawing. We however forgot to send the notification at the end of the defer.
This likely has a small perf impact. We however do need these cursor position events for IMEs to be able to track the cursor position (and low key for #10821)
* [x] regressed in #10685
* [x] Closes#11170
* [x] I work here
* [x] Tests added
This gets rid of warnings like
```
NU1102: Unable to find package Microsoft.NETCore.App.Host.win-x64 with version (= 3.1.21)
- Found 1 version(s) in TerminalDependencies [ Nearest version: 3.1.18 ]
```
Technically, there's a `NETCore.App.Host.3.1.21` that's out now. We _could_
migrate to that, but then we'd have to make sure to manually re-upload that
nuget package to our nuget feed, and then we'd still get this warning the
next time that package is updated.
Theoretically, there's a 6.x version too, but considering this is a debugging
tool, we don't care all that much.
* [x] I work here
* [x] Discussed this with Dustin
* [x] Gets rid of a SUPER TRIVIAL warning.
Since `AtlasEngine` prefers drawing without alpha for performance reasons,
calls to `EnableTransparentBackground` require a draw cycle.
This PR makes `Renderer::_NotifyPaintFrame` public and calls it.
Related to #9999.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Open Windows Terminal command palette
* Choose "Set background opacity..."
* Cycling through the items without selecting one
changes background opacity immediately ✅
`Renderer` owns the information of the hovered interval in `_hoveredInterval`
and provides no access to this information. We can only infer it from calls
to `PaintBufferGridLines`, if we're given the request to draw an underline
despite the previous call to `UpdateDrawingBrushes` not specifying it.
While it'd be possible to fix this and pass the underline flag to
`UpdateDrawingBrushes`, I personally consider this aspect of `Renderer` to be
a "leaky abstraction" as it's inherently incompatible with any engine not
working like `DxEngine`, such as the `AtlasEngine`. It's likely more
worthwhile to fundamentally change the `Renderer` architecture in the future.
## PR Checklist
* [x] Closes#11871
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Launch pwsh.exe
* Hyperlinks are underlined when hovered ✅
* Launch WSL / bash
* Run `printf '\e]8;;http://example.com\e\\This is a link\e]8;;\e\\\n'`
* Hyperlink is underlined when hovered ✅
Less "merge conflict" and more "something that got missed in a merge".
The offending commits are
* 68ab807
* b3fab51
The Fuzzer build doesn't run on PR, so it didn't notice this couldn't build.
@carlos-zamora as an FYI
This commit also introduces a check that we are in an interactive
session before we perform handoff, so as to not break service accounts.
It also adds some tracing.
The only way to notice that LeaveCriticalSection() was called more
often than EnterCriticalSection() is by calling EnterCriticalSection()
again in the future, which will then deadlock.
Since this bug occurs on exit it wasn't noticeable with the old console lock.
With the new, stricter ticket lock this bug causes a fail-fast exit.
## PR Checklist
* [x] Closes#12168
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Launch and then exit Windows Terminal
* OpenConsole cleanly exits ✅
This is a collection of fixes:
* dd213a5c18: This was a crash I discovered while investigating. Probably not the root cause crash, but a crash nonetheless.
* ba491212afcbafdabc89d88b78f1dc5076dea0c3...0b18ae4ed73cbb15452c7c15aefa0c2671db9605: A collection of fixes to _not_ create the window when we're about to handoff each of the new tabs, panes, to an elevated window. That should prevent us from starting up XAML at all, which should take care of #12169. Additionally, it'll prevent us from restoring the unelevated windows, which should resolve#12190
* The remainder of the commits where fixes for other weird edge cases as a part of this. Notably:
* ff72599189: Autopromote the first `split-pane` to a new tab, in the case that it's preceded with only `new-tab` actions that opened elevated windows.
#### checklist
* [x] I work here
* [x] Docs are fine
* [x] Closes#12190
* [x] Closes#12169
This commit correctly restores the previous opacity when the command palette
preview is cancelled. It includes an additional change in order to make the
`AdjustOpacity` setter consistent and symmetric with the `Opacity` getter.
## PR Checklist
* [x] Closes#12228
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Open Windows Terminal command palette
* Choose "Set background opacity..."
* Cycle through the items without selecting one
* Press Escape
* Previous opacity is restored ✅
This minor change makes it possible to hot-reload the AtlasEngine shaders under
Windows Terminal. Launching an UWP application from Visual Studio doesn't
necessarily result in a working directory inside the project folder,
which makes relative file paths impractical. While the `__FILE__` macro is
compiler dependent it works under our build setup with MSVC at least.
## Validation Steps Performed
* Shader hot-reloading works under Windows Terminal ✅
With the introduction of a common `RenderSettings` class in 62c95b5,
`PaintBufferGridLines` was now uniformly called with a proper alpha-less
`COLORREF` argument. This commit crudely fixes the issue by forcing
the color to be fully opaque in the `DxEngine` class.
## PR Checklist
* [x] Closes#12223
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Launch pwsh.exe
* Hyperlinks get underlines on hover ✅
When title updates are forwarded from the host to the client terminal,
they're passed over conpty in an `OSC 0` sequence. If there are any
control characters embedded in that title text it's essential they be
filtered out, otherwise they are likely to be misinterpreted by the VT
parser on the other side. This PR fixes a case where that sanitization
step was missed for titles initialized at startup.
Originally the sanitization step was handled in `DoSrvSetConsoleTitleW`,
which catches title changes made via VT escape sequences, or through the
console API, but missed the title initialization at startup. I've now
moved that sanitization code into the `CONSOLE_INFORMATION::SetTitle`
method, which should cover all cases.
This sanitization is only meant to occur when in "pty mode", though,
which we were originally establishing with an `IsInVtIoMode` call.
However, `IsInVtIoMode` does not return the correct result when the
title is set at startup, since the VT I/O thread is not initialized at
that point. So I've instead had to change that to an `InConptyMode`
call, which determines the conpty state from the launch args.
## Validation Steps Performed
I've manually confirmed the test case described in issue #12206 is now
working correctly.
However, the change to using `InConptyMode` caused some of the unit
tests to fail, because there isn't a real conpty connection when
testing. Fortunately there are some `EnableConptyModeForTests` methods
used by the unit tests to fake the appearance of a conpty connection,
and I just needed to add some additional state in one of those methods
to trigger the correct `InConptyMode` response.
Closes#12206
The atlas engine currently applies colors and flags (underline,
overline, ...) based on the first column in a glyph; this means that
every member of a ligature is drawn in the same color with the same
underline style.
This commit makes us look up cell color and flags based on the actual
buffer column it represents, so that ligatures can be printed in
multiple colors and with different underline styles.
## Summary of the Pull Request
This PR sets up a OneFuzz pipeline on Azure DevOps for our repo.
## Detailed Description of the Pull Request / Additional comments
- fuzz.yml: defines the stages and pipeline for ADO
- build-console-fuzzing: builds the solution in the Fuzzing configuration
- build-console-steps: omits a few tasks that are unnecessary for this build configuration
- sln and vcxproj changes: the solution wasn't building in CI. This makes sure that's fixed.
- fuzzing.md: a short guide on how to get OneFuzz set up and add a new fuzzer
## References
#7638
[Git2Git] Merged PR 6814613: conhost FT: skip a test that fails on OneCore
Fixes MSFT-33720056
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 6410311eee21e9ce147464af89d35f3569d4d2b9
## Summary of the Pull Request
Disables the automatic adjustment of indistinguishable text (added in #11095) because of the concerns brought up in #11917. Also, the setting is hidden in the SUI for as long as this feature remains disabled.
## 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
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Summary of the Pull Request
Prevents a potential null pointer crash in the export buffer action.
## PR Checklist
* [x] Closes#12170
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema 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
## Validation Steps Performed
Manually tested.
This commit replaces the console lock was replaced with a fair ticket
lock implementation, as only fair locks guarantee us that the renderer
(or other parts) can acquire the lock, once the VT parser has finally
released it.
This is related to #11794.
## Validation Steps Performed
* No obvious crashes ✅
* No text/VT performance regression ✅
* Cursor blinker starts/stops on focus/defocus of the window ✅
## Summary of the Pull Request
This PR moves the color table and related render settings, which are common to both conhost and Windows Terminal, into a shared class that can be accessed directly from the renderer. This avoids the overhead of having to look up these properties via the `IRenderData` interface, which relies on inefficient virtual function calls.
This also introduces the concept of color aliases, which determine the position in the color table that colors like the default foreground and background are stored. This allows the option of mapping them to one of the standard 16 colors, or to have their own separate table entries.
## References
This is a continuation of the color table refactoring started in #11602 and #11784. The color alias functionality is a prerequisite for supporting a default bold color as proposed in #11939. The color aliases could also be a way for us to replace the PowerShell color quirk for #6807.
## PR Checklist
* [x] Closes#12002
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema 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
## Detailed Description of the Pull Request / Additional comments
In addition to the color table, this new `RenderSettings` class manages the blinking state, the code for adjusting indistinguishable colors, and various boolean properties used in the color calculations. These boolean properties are now stored in a `til::enumset` so they can all be managed through a single `SetRenderMode` API, and easily extended with additional modes that we're likely to need in the future.
In Windows Terminal we have an instance of `RenderSettings` stored in the `Terminal` class, and in conhost it's stored in the `Settings` class. In both cases, a reference to this class is passed to the `Renderer` constructor, so it now has direct access to that data. The renderer can then pass that reference to the render engines where it's needed in the `UpdateDrawingBrushes` method.
This means the renderer no longer needs the `IRenderData` interface to access the `GetAttributeColors`, `GetCursorColor`, or `IsScreenReversed` methods, so those have now been removed. We still need access to `GetAttributeColors` in certain accessibility code, though, so I've kept that method in the `IUIAData` interface, but the implementation just forwards to the `RenderSettings` class.
The implementation of the `RenderSettings::GetAttributeColors` method is loosely based on the original `Terminal` code, only the `CalculateRgbColors` call has now been incorporated directly into the code. This let us deduplicate some bits that were previously repeated in the section for adjusting indistinguishable colors. The last steps, where we calculate the alpha components, have now been split in to a separate `GetAttributeColorsWithAlpha` method, since that's typically not needed.
## Validation Steps Performed
There were quite a lot changes needed in the unit tests, but they're mostly straightforward replacements of one method call with another.
In the `TextAttributeTests`, where we were previously testing the `CalculateRgbColors` method, we're now running those tests though `RenderSettings::GetAttributeColors`, which incorporates the same functionality. The only complication is when testing the `IntenseIsBright` option, that needs to be set with an additional `SetRenderMode` call where previously it was just a parameter on `CalculateRgbColors`.
In the `ScreenBufferTests` and `TextBufferTests`, calls to `LookupAttributeColors` have again been replaced by the `RenderSettings::GetAttributeColors` method, which serves the same purpose, and calls to `IsScreenReversed` have been replaced with an appropriate `GetRenderMode` call. In the `VtRendererTests`, all the calls to `UpdateDrawingBrushes` now just need to be passed a reference to a `RenderSettings` instance.
This commit makes the following changes to `til::point/size/rectangle`
for the following reasons:
* Rename `rectangle` into `rect`
This will make the naming consistent with a later `small_rect` struct
as well as the existing Win32 POINT/SIZE/RECT structs.
* Standardizes til wrappers on `int32_t` instead of `ptrdiff_t`
Provides a consistent behavior between x86 and x64, preventing accidental
errors on x86, as it's less rigorously tested than x64. Additionally it
improves interop with MIDL3 which only supports fixed width integer types.
* Standardizes til wrappers on throwing `gsl::narrow_error`
Makes the behavior of our code more consistent.
* Makes all eligible functions `constexpr`
Because why not.
* Removes implicit constructors and conversion operators
This is a complex and controversial topic. My reasons are: You can't Ctrl+F
for an implicit conversion. This breaks most non-IDE engines, like the one on
GitHub or those we have internally at MS. This is important for me as these
implicit conversion operators aren't cost free. Narrowing integers itself,
as well as the boundary checks that need to be done have a certain,
fixed overhead each time. Additionally the lack of noexcept prevents
many advanced compiler optimizations. Removing their use entirely
drops conhost's code segment size by around ~6.5%.
## References
Preliminary work for #4015.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
I'm mostly relying on our unit tests here. Both OpenConsole and WT appear to work fine.
In previous releases, we had the commandlines for the Command Prompt and PowerShell profiles unqualified, as `cmd.exe` and `powershell.exe`. This was bad - theoretically, that would have preferred the cmd that was in the CWD over the one in System32. Or, something could insert itself into the path, and you'd end up with a malicious `cmd.exe` before the real one.
In #11437, we made sure that the `userDefaults` are initiated with the fully qualified paths. However, that didn't fix the issue for folks who already had settings files.
In an effort to better prevent this kind of badness, if we see a profile _with a default profile guid_, AND the unqualified version of the path, then we'll stealth replace it with the fully qualified one.
* Related to #11437
* [x] fixes#12126
* [x] Tests added
Adds an action which can be used to change the opacity at runtime. This is a follow up to some of the other work I had been doing around opacity and settings previewing at the end of the year.
> edit: pseudo-spec
>
> * `adjustOpacity`:
> * `"opacity"`: (**required**) an integer number to set the opacity to.
> * `"relative"`: (defaults to `true`)
> * If false, set the opacity to the given value, which should be between [0, 100].
> * If true, then use `opacity` as a relative adjustment to the current opacity. So the implementation would get the current opacity for this pane, then add this action's opacity to that value. Should be between [-100, 100]
>
> This would allow both setting exactly 25% opacity with an action, and binding an action that increases/decreases the opacity one {amount}
It's preview-able too, which is neat.
* [x] Closes#11205
* [x] I work here
* [x] Docs updated: https://github.com/MicrosoftDocs/terminal/pull/477
When I added these macros in #11619, the real purpose was to make sure we don't forget to add new settings to these test mocks as well. However, I totally forgot to convert those. I guess that happens with a 1300 line diff ¯\\\_(ツ)_/¯
* [x] Is a codehealth thing
* [x] I work here
* [x] tests still pass
This was a simple oversight. No user profile ever has `connectionType` set, because why would they. So even for the Azure Shell, which needed this, the check would fail and we'd forget to duplicate the connectionType to the new profile.
* [x] I work here
* [x] Closes#12120
* [x] Tested manually
Title says it all. This is on by default, and we've committed to keeping it around. Having a velocity flag for it is redundant now.
* [x] Closes#11454
* [x] I work here
2022-01-12 18:36:47 +00:00
659 changed files with 22358 additions and 15991 deletions
[allow/*.txt](allow/) | Add words to the dictionary | one word per line (only letters and `'`s allowed) | [allow](https://github.com/check-spelling/check-spelling/wiki/Configuration#allow)
[reject.txt](reject.txt) | Remove words from the dictionary (after allow) | grep pattern matching whole dictionary words | [reject](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-reject)
[patterns/*.txt](patterns/) | Patterns to ignore from checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[candidate.patterns](candidate.patterns) | Patterns that might be worth adding to [patterns.txt](patterns.txt) | perl regular expression with optional comment block introductions (all matches will be suggested) | [candidates](https://github.com/check-spelling/check-spelling/wiki/Feature:-Suggest-patterns)
[line_forbidden.patterns](line_forbidden.patterns) | Patterns to flag in checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[expect/*.txt](expect.txt) | Expected words that aren't in the dictionary | one word per line (sorted, alphabetically) | [expect](https://github.com/check-spelling/check-spelling/wiki/Configuration#expect)
[advice.md](advice.md) | Supplement for GitHub comment when unrecognized words are found | GitHub Markdown | [advice](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice)
Note: you can replace any of these files with a directory by the same name (minus the suffix)
and then include multiple files inside that directory (with that suffix) to merge multiple files together.
<!-- See https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice --> <!-- markdownlint-disable MD033 MD041 -->
<details>
<summary>
:pencil2: Contributor please read this
@@ -6,7 +6,7 @@
By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
:warning: The command is written for posix shells. You can copy the contents of each `perl` command excluding the outer `'` marks and dropping any `'"`/`"'` quotation mark pairs into a file and then run `perl file.pl` from the root of the repository to run the code. Alternatively, you can manually insert the items...
:warning: The command is written for posix shells. If it doesn't work for you, you can manually _add_ (one word per line) / _remove_ items to `expect.txt` and the `excludes.txt` files.
If the listed items are:
@@ -20,31 +20,29 @@ See the `README.md` in each directory for more information.
:microscope: You can test your commits **without***appending* to a PR by creating a new branch with that extra change and pushing it to your fork. The [check-spelling](https://github.com/marketplace/actions/check-spelling) action will run in response to your **push** -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. :wink:
<details><summary>:clamp: If you see a bunch of garbage</summary>
If it relates to a ...
<details><summary>well-formed pattern</summary>
<details><summary>If the flagged items are :exploding_head: false positives</summary>
See if there's a [pattern](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns) that would match it.
If items relate to a ...
* binary file (or some other file you wouldn't want to check at all).
If not, try writing one and adding it to a `patterns/{file}.txt`.
Please add a file path to the `excludes.txt` file matching the containing file.
Patterns are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines.
Note that patterns can't match multiline strings.
</details>
<details><summary>binary-ish string</summary>
Please add a file path to the `excludes.txt` file instead of just accepting the garbage.
File paths are Perl 5 Regular Expressions - you can [test](
File paths are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your files.
`^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md](
`^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md](
../tree/HEAD/README.md) (on whichever branch you're using).
</details>
* well-formed pattern.
If you can write a [pattern](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns) that would match it,
try adding it to the `patterns.txt` file.
Patterns are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines.
# Update Lorem based on your content (requires `ge` and `w` from https://github.com/jsoref/spelling; and `review` from https://github.com/check-spelling/check-spelling/wiki/Looking-for-items-locally )
@@ -302,6 +299,7 @@ If you would like to ask a question that you feel doesn't warrant an issue
* Universal Windows Platform Development
* **The following Individual Components**
* C++ (v142) Universal Windows Platform Tools
* You must install the [.NET Framework Targeting Pack](https://docs.microsoft.com/dotnet/framework/install/guide-for-developers#to-install-the-net-framework-developer-pack-or-targeting-pack) to build test projects
<!-- Mandatory. Minor version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Mandatory, defaults to 0. Patch version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Optional, defaults to empty. Prerelease version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- This file is read by XES, which we use in our Release builds. -->
<PropertyGroup Label="Version">
<!--
The Windows 11 build is going to have the same package name, so it *must* have a different version.
The easiest way for us to do this is to add 1 to the revision field.
In short, for a given Terminal build 1.11, we will emit two different versions (assume this is build
4 on day 23 of the year):
- 1.11.234.0 for Windows 10
- 1.11.235.0 for Windows 11
This presents a potential for conflicts if we want to ship two builds produced back to back on the
same day... which is terribly unlikely.
-->
<VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>
@@ -163,7 +163,7 @@ Given that we're using Xaml islands to host a modern UI and stitching a DirectX
Now, the obvious followup question is _"why can't you have one elevated connection in a tab next to a non-elevated connection?"_ This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.
[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.
[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.
Running a process elevated _severs_ that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.
Most Nuget package references in this project are centralized in a single configuration so that there is a single canonical version for everything. This canonical version is restored before builds by the build pipeline, environment initialization scripts, or Visual Studio (as appropriate).
The canonical version numbers are defined in dep/nuget/packages.config. That defines what will be downloaded by nuget.exe. Most Nuget packages also have a .props and/or .targets file that must be imported by every project that consumes it. Those import statements are consolidated in:
- src/common.nugetversions.props
- src/common.nugetversions.targets
When a globally managed version changes all three of those files must be changed in unison.
Certain Nuget package references in this project, like `Microsoft.UI.Xaml`, must be updated outside of the Visual Studio NuGet package manager. This can be done using the snippet below.
> Note that to run this snippet, you need to use WSL as the command uses `sed`.
To update the version of a given package, use the following snippet
"description":"This will override the profile's `elevate` setting."
},
}
},
"type":"object"
},
@@ -860,7 +861,7 @@
}
}
}
],
]
},
"SetFullScreenAction":{
"description":"Arguments for a setFullScreen action",
@@ -880,7 +881,7 @@
}
}
}
],
]
},
"SetMaximizedAction":{
"description":"Arguments for a setMaximized action",
@@ -900,7 +901,7 @@
}
}
}
],
]
},
"WtAction":{
"description":"Arguments corresponding to a wt Action",
@@ -1385,6 +1386,34 @@
}
]
},
"AdjustOpacityAction":{
"description":"Changes the opacity of the active Terminal window. If `relative` is specified, then this action will increase/decrease relative to the current opacity.",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"adjustOpacity"
},
"opacity":{
"type":"integer",
"minimum":-100,
"maximum":100,
"default":0,
"description":"How opaque the terminal should become or how much the opacity should be changed by, depending on the value of `relative`"
},
"relative":{
"type":"boolean",
"default":true,
"description":"If true, then adjust the current opacity by the given `opacity` parameter, additively. If false, set the opacity to exactly that value."
}
}
}
]
},
"Keybinding":{
"additionalProperties":false,
"properties":{
@@ -1493,6 +1522,9 @@
{
"$ref":"#/$defs/QuakeModeAction"
},
{
"$ref":"#/$defs/AdjustOpacityAction"
},
{
"type":"null"
}
@@ -1601,7 +1633,7 @@
"$ref":"#/$defs/CopyFormat"
},
"trimBlockSelection":{
"default":false,
"default":true,
"description":"When set to true, trailing white-spaces will be removed from text in rectangular (block) selection while copied to your clipboard. When set to false, the white-spaces will be preserved.",
"type":"boolean"
},
@@ -1677,7 +1709,7 @@
},
"startOnUserLogin":{
"default":false,
"description":"When set to true, this enables the launch of Windows Terminal at startup. Setting this to false will disable the startup task entry. If the Windows Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect.",
"description":"When set to true, this enables the launch of Terminal at startup. Setting this to false will disable the startup task entry. If the Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect.",
"type":"boolean"
},
"firstWindowPreference":{
@@ -1729,7 +1761,7 @@
},
"useAcrylicInTabRow":{
"default":false,
"description":"When set to true, the tab row will have an acrylic background with 50% opacity.",
"description":"When set to true, the tab row will have an acrylic material background with 50% opacity.",
"type":"boolean"
},
"actions":{
@@ -2019,6 +2051,10 @@
"default":false,
"description":"When true, this profile should always open in an elevated context. If the window isn't running as an Administrator, then a new elevated window will be created."
},
"experimental.connection.passthroughMode":{
"description":"When set to true, directs the PTY for this connection to use pass-through mode instead of the original Conhost PTY simulation engine. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean"
},
"experimental.retroTerminalEffect":{
"description":"When set to true, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean"
@@ -2027,6 +2063,11 @@
"description":"Use to set a path to a pixel shader to use with the Terminal. Overrides `experimental.retroTerminalEffect`. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"string"
},
"experimental.useAtlasEngine":{
"description":"Enable using the experimental new rendering engine for this profile. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean",
"default":false
},
"fontFace":{
"default":"Cascadia Mono",
"description":"[deprecated] Define 'face' within the 'font' object instead.",
@@ -2187,7 +2228,7 @@
},
"useAcrylic":{
"default":false,
"description":"When set to true, the window will have an acrylic background. When set to false, the window will have a plain, untextured background.",
"description":"When set to true, the window will have an acrylic material background. When set to false, the window will have a plain, untextured background.",
OpenConsole can be built with a `Fuzzing` configuration. To set up a fuzzer, you'll need an `LLVMFuzzerTestOneInput` function. This serves as a way for the fuzzer to attach itself and inject tests into your fuzz target.
To build the fuzzer locally, build the OpenConsole solution in the `Fuzzing` configuration. This should output an executable that runs the fuzzer on the provided test case. In the case of PR #9604, the desired executable is located at `bin\x64\Fuzzing\OpenConsoleFuzzer.exe`.
OneFuzz allows us to run our fuzzers in CI and be alerted of new bugs found in this endeavor.
### Installing OneFuzz
You can download the latest OneFuzz CLI on their [releases page](https://github.com/microsoft/onefuzz/releases).
### Configuring OneFuzz
To run OneFuzz locally, you'll need to configure its endpoint, client ID, and client secret. Windows has a preset configuration available; this can be found at [this tutorial](https://www.osgwiki.com/wiki/Fuzzing_Service_-_Azure_Edge_and_Platform#Configure_OneFuzz_CLI) on osgwiki.
-`build`: the identifier for the build (i.e. commit SHA1)
-`pool`: the VM pool to run this on
-`exe_path`: the fuzzer executable output from building your project
This should also output more information (i.e. job ID) about the newly created job in a JSON format.
### Enabling notifications
**NOTE**: Our pipeline is already set up with this functionality. However, here is a quick guide on how to get it set up and modify it to our liking.
OneFuzz supports multiple notification systems at once including MS Teams and Azure DevOps. See the resources below to learn more about setting these up.
Our pipeline has been set up to create Azure DevOps work items.
@@ -60,7 +60,7 @@ Users will be able to add a new setting to their font objects (added in [#10433]
There is one point to note here about clashing. For example, if a user has the old "weight" setting defined _as well as_ a "wght" axis defined, we will only use the "wght" axis value. We prioritize that value for a few reasons:
1. It is the more recent addition to our settings model. Thus, it is likely that a user that has defined both values probably just forgot to remove the old value.
2. It is the more precise value, it is a specific float value whereas the the old "weight" setting is an enum (that eventually gets mapped to a float value).
2. It is the more precise value, it is a specific float value whereas the old "weight" setting is an enum (that eventually gets mapped to a float value).
## Capabilities
@@ -74,7 +74,7 @@ Should not affect security.
### Reliability
Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existant feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existent feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
The idea is for Windows Terminal to change automatically its color schemes according to what theme is selected, including the case where `system` theme is selected.
## Inspiration
I work remotely as a developer, so I have to spend a lot of hours in front of my PC screen. In my setup, right behind my desk I have a window, which is the only source of natural sunlight in my room.
Normally I like dark modes in all the programs and apps I use, but when there's too much sunlight, it becomes annoying, and sometimes even painful, to work in dark mode. So, I have all the programs and apps I use (at least, those that can) set to switch their color themes to what the system has.
The company I work for sent me a Macbook Pro, and my personal phone is an Android, both with automatic dark mode at sunset and light mode at sunrise, and in those devices it's been working relatively well. In Windows, as it is known, there's no such feature, so I manually change between dark and light mode when it's needed, and most of the programs and apps I use go along with this change. Windows Terminal, is not one of them.
The theme changes just as expected, but in an app like this, this change only affects the top of the window, leaving almost all of the screen at the mercy of what the color scheme is, and it doesn't depend on the theme, which defeats any attempt to make a good use of the `system` theme feature.
## Solution Design
Could be implemented in the form of:
```json
"colorScheme":{
"light":"BlulocoLight",
"dark":"BlulocoDark"
}
```
or:
```json
"colorSchemeLight":"BlulocoLight",
"colorSchemeDark":"BlulocoDark"
```
## UI/UX Design
In a first version it could look like the terminal in Visual Studio Code, and an improvement could be to have light mode specific color schemes, just like those already present in Windows terminal. A good idea could be to get an inspiration in Dark++ and Light++ VSCode color themes.
A user could benefit from a more healthy light level contrast between the screen their looking at and the environment they are, reducing the risk of headache or developing/intensifying eye problems, and any other related eye conditions. Plus, it adds to a more consistent experience between different programs and apps, and the system itself.
## Capabilities
### Accessibility
This feature improves accessibility more than any other capability, because the key is to be able to read and see anything better when the environment, both the external to the device, and the device's system itself, is in a certain mode (dark/light).
### Security
The proposed solution is based in the current way one sets Windows Terminal settings, so it isn't expected to add any security issues.
### Reliability
Adding this feature would make Windows Terminal more reliable when it's expected that it changes it's visual theme/color scheme along with the whole system.
### Compatibility
The solution is not expected to break anything.
### Performance, Power, and Efficiency
It might increase the energy spent in the cases where people who were used to use the terminal in regular dark color schemes start using more light color schemes, but that is the case for any other program that shows lighter colors and I don't think the increment would be as high as to be even considered a downside.
## Potential Issues
Some users might not like the change in color schemes or be too used to the terminal being dark, but this may be avoided making the current schemes a default and adding this solution as an alternative setting.
## Future considerations
This solution might bring more attention to the color schemes setting, even more when considering light mode specific color schemes
## Resources
Inspired by what's been said in the issue comments. Credits to them.
Since the beginning, Windows has offered a single choice in default terminal hosting behavior. Specifically, the default terminal is defined as the one that the operating system will start on your behalf when a command-line application is started without a terminal attached. This specification intends to detail how we will offer customers the ultimate in choice among first and third party replacements for their default terminal experience.
## Inspiration
We've had a lot of success in the past several years on our terminal team journey. We updated the old console host user interface with long-desired features. We updated the console environment to bring Windows closer to Linux and Mac by implementing the client (receiving) end of Virtual Terminal sequences to unlock WSL, Docker, and other cross-platform command-line application compatibility. We then created the ConPTY to expose the server end of the console environment to first and third party applications to enable the hosting of any of those command-line clients within their own user interfaces by implementing the server (sending) end of Virtual Terminal sequences. And then we built Windows Terminal as our flagship implementation of the development environment on this model.
Through all of this, the entrypoint for alternatives to the console host UX continued to be "Start your alternative terminal implementation first, then start the command-line application inside." For those familiar with Linux and Mac or for those using the broad ecosystem of alternative Windows Terminals like ConEmu, Cmder, Console2, and the like... that was natural. But Windows did it differently a long time ago allowing the starting of a command-line application directly from the shell or kernel without a terminal specified. On noticing the missing terminal, the system would just-in-time start and attach the one terminal it could count on as always present, `conhost.exe`.
And so the inspiration of this is simple: We want to allow our customers to choose whichever terminal they want as the just-in-time terminal attached to an application without one present/specified on launch. This final move completes our journey to allow the ultimate in choice AND decouple the terminal experience from the operating system release schedule.
## Solution Design
There are three components to the proposed design:
1.**Inbox console**: This is the `conhost.exe` that is resident inside every Windows installation.
1.**Updated console**: This is the `openconsole.exe` that we ship with the Windows Terminal to provide a more up-to-date console server experience.
1.**Terminal UX**: This is `WindowsTerminal.exe`, the new Terminal user interface that runs on VT sequences.
And there are a few scenarios here to consider:
1. Replacement console API server and replacement terminal UX.
1. This is the Windows Terminal scenario today. `OpenConsole.exe` is packed in the package to be the console API server and ConPTY environment for `WindowsTerminal.exe`.
1. Replacement console API server and legacy terminal UX.
1. We don't explicitly distribute this today, but it's technically possible to just run `OpenConsole.exe` to accomplish this.
1. Inbox console API server and replacement terminal UX.
1. The WSL environment does this when doing Windows interop and I believe VS Code does this too when told to use the ConPTY environment. (And since VS Code does it, anything using node-pty also does it, covering some 3rd party terminals as well).
1. Inbox console API server and inbox terminal UX.
1. This is what we have today in `conhost.exe` running as the default application.
The goal is to offer the ultimate in choice here where any of the components can be replaced as necessary for a 1st or 3rd party scenario.
### Overview
#### Inbox console
The inbox console will be updated to support delegation of the incoming console client application connection to another console API server if one is registered and available.
We leave the inbox console in-place and always available on the operating system for these reasons:
1. A last chance fall-back should any of the delegation operations fail
1. An ongoing host for applications that aren't going to need a window at all
1. Continued support of our legacy `conhostv1.dll` environment, if chosen
The general operation is as follows:
- A command-line client application is started (from the start menu, run box, or any other `CreateProcess` or `ShellExecute` route) without an existing console server attached
- The inbox console is launched from `C:\windows\system32\conhost.exe` as always by the initialization routines inside `kernelbase.dll`.
- The inbox console accepts the incoming initial connection and looks for the `ShowWindow` information on the connection packet, as received from the kernel's process creation routines based on the parameters given to the `CreateProcess` call. (See [CREATE_NO_WINDOW](https://docs.microsoft.com/en-us/windows/win32/procthread/process-creation-flags) flag for details.)
- If the session is about to create a window, check for registration of a delegated/updated console and hand-off to it if it exists.
- Otherwise, start normally.
This workflow affords us several benefits:
- The only inbox component we have to change is `conhost.exe`, the one we already regularly update from open source on a regular basis. There is no change to the `kernelbase.dll` console initialization routines, `conclnt.lib` communication protocol, nor the `condrv.sys` driver.
- We should be able to make this change quickly, relatively easily, and the code delta should be relatively small
- This makes it easy to squeeze in early in the development of the solution and get it into the Windows OS product as soon as possible for self-hosting, validation, and potentially shipping in the OS before the remainder of the solution has shaken out
- This also makes it potentially possible to backport this portion of the code change to popular in-market versions of Windows 10. For instance, WSL2 has just backported to 1903 and 1909. The less churn and risk, the easier it is to sell a backport.
*Potential future:*
- ~~If no updated console exists, potentially check for registration of a terminal UX that is willing to use the inbox ConPTY bits, start it, and transition to being a PTY instead.~~
- **CUT FROM v1**: To simplify the story for end-users, we're offering this as a package deal in the first revision. Explaining the difference between consoles and terminals to end users is very difficult.
The registration would operate as follows:
- A registry key in `HKCU\Console\%%Startup` (format `REG_SZ`, name `DelegationConsole`) would specify ~~the path to ~~the replacement console that would be used to service the remainder of the connection process.
- Alternatively or additionally, this same `REG_SZ` could list a COM server ID that could be looked up in the classes root and invoked. **V1 NOTE:** This was what was done.
- Packaged applications and classic applications can easily register a COM server
- WinRT libraries should be able to be easily registered as the COM server as well (given WinRT is COM underneath)
- WinRT cannot be exposed outside of the package context itself, so the `conhost.exe` that is in the OS and is naturally outside the package cannot find it.
- **V1 NOTE:** The subkey `%%Startup` was chosen to separate these keys (this one and the `DelegationTerminal` one below) in case we needed to ACL them or protect them in some way. We want a per-user choice of which Terminal/Console are used, but we might need to take action to prevent these keys from being slammed at some point in the future. Why `%%`? The subkeys are traditionally used to resolve paths to client binaries that have their own console preferences set. The `%%` should never be resolvable as it won't lead to a valid path or expanded path variable.
The delegation process would operate as follows:
- A method contract is established between the existing inbox console and any updated console (an interface).
-`HANDLE server`: This is the server side handle to the console driver, used with `DeviceIoControl` to receive/send messages with the client command-line application
-`HANDLE driverInputEvent`: The input event is created and assigned to the driver immediately on first connection, before any messages are read from the driver, to ensure that it can track a blocking state should first message be an input request that we do not yet have data to fill. As such, the inbox console will have created this and assigned it to the driver before pulling off the connection packet and determining that it wants to delegate. Therefore, we will transfer ownership of this event to the updated console.
- ~~`const PortableArguments* const args`: This contains the startup argument information that was passed in when the process was started including the original command line and the in/out handles.~~
- ~~The `ConsoleArguments` structure could technically change between versions, so we will make a version agnostic portable structure that just carries the communication from the old one to the new one.~~
- **CUT FROM V1**: The only arguments coming in from a default light-up are the server handle. Pretty much all the other arguments are related to the operation of the PTY. Since this feature is about "default application" launches where no arguments are specified, this was cut from the initial revision.
-`const PortableConnectMessage* const msg`:
- The `CONSOLE_API_MSG` structure contains both the actual packet data from the driver as well as some overhead/administration data related to the packet state, ordering, completion, errors, and buffers. It's a broad scope structure for every type of message we process and it can change over time as we improve the way the `conserver.lib` handles packets.
- This represents a version agnostic variant for ONLY the connect message that can pass along the initial connect information structure, the packet sequencing information, and other relevant payload only to that one message type. It will purposefully discard references to things like a specific set of API servicing routines because the point of handing off is to get updated routines, if necessary.
- **V1 NOTE:** This was named `CONSOLE_PORTABLE_ATTACH_MSG`
-`HANDLE signalPipe`: During authoring, it was identified that <kbd>Ctrl+C</kbd> and other similar signals need to make it back to the original `conhost.exe` application as the Operating System grants it special privilege over the originally attached client application. This privilege cannot be transferred to the delegated console. So this channel remains for the delegated one to send its signals back through the original one for commanding the underlying client. (This also implies the original `conhost.exe` inbox cannot close and must remain a part of the process tree for the life of the session to maintain this control.)
-`HANDLE inboxProcess`: Since we have to keep the inbox `conhost.exe` running for signal/ownership reasons, we also need to track its lifetime. If it disappears for whatever reason, we need to tear down the entire chain as part of our operation has been compromised.
-`HANDLE* process`: On the contrary to `inboxProcess`, we need to give our process handle back so it can also be tracked. After the inbox console delegates, it remains in a very limited capacity. If the delegation one disappears, the session will no longer function and needs to be torn down (and the client closed).
- *Return* `HRESULT`: This is one of the older style methods in the initialization. We moved them from mostly `NTSTATUS` to mostly `HRESULT` a while ago to take advantage of `wil`. This one will continue to follow the pattern and not move to exceptions. A return of `S_OK` will symbolize that the handoff worked and the inbox console can clean itself up and stop handling the session.
- When the connection packet is parsed for visibility information (see `srvinit.cpp`), we will attempt to resolve the registered handoff and call it.
- ~~In the initial revision here, I have this as a `LoadLibrary`/`GetProcAddress` to the above exported contract method from the updated console. This maintains the server session in the same process space and avoids:~~
1.~~The issue of passing the server, event, and other handles into another process space. We're not entirely sure if the console driver will happily accept these things moving to a different process. It probably should, but unconfirmed.~~
1.~~Some command-line client applications rely on spelunking the process tree to figure out who is their servicing application. Maintaining the delegated/updated console inside the same process space maintains some level of continuity for these sorts of applications.~~
- **Alternative:** We may make this just be a COM server/client contract. ~~An in-proc COM server should operate in much the same fashion here (loading the DLL into the process and running particular method) while being significantly more formal and customizable (version revisions, moving to out-of-proc, not really needing to know the binary path because the catalog knows).~~
- **V1 NOTE:** We landed on an out-of-proc COM server/client here. This maintains the isolation of the newly running code from the old code. Since we're maintaining the original `conhost.exe` for signaling purposes, we're no longer worried about the spelunking the process tree and not having the relationship for clients to find.
- **Not considering:** ~~WinRT. `conhost.exe` has no WinRT. Adding WinRT to it would significantly increase the complexity of compilation in the inbox and out of box code base. It would also significantly increase the compilation time, binary size, library link list, etc... unless we use just the ABI to access it. But I don't see an advantage to that over just using classic COM at that point. This is only one handoff method and a rather simplistic one at that. Every benefit WinRT provides is outweighed by the extra effort that would be required over just a classic COM server in this case.~~
- After delegation is complete, the inbox console will have to clean up any threads, handles, and state related to the session. We do a fairly good job with this normally, but some portions of the `conhost.exe` codebase are reliant on the process exiting for final cleanup. There may be a bit of extra effort to do some explicit cleanup here.
- **V1 NOTE:** The inbox one cleans up everything it can and sits in a state waiting for the child/delegated process handle to exit. It also maintains a thread listening for the signals to come through in case it needs to send a command to the client application using the privilege granted to it by the driver.
#### Updated console
The updated replacement console will have the same console API server capabilities as the inbox console, but will be a later, updated, or customized-to-the-scenario version of the API server generally revolving around improving ConPTY support for a Terminal application.
On receiving the handoff from the method signature listed above, the updated console will:
- Establish its own set of IO threading, device communication infrastructure, and API messaging routines while storing the handles given
- ~~Re-parse the command line arguments, if necessary, and store them for guiding the remainder of launch~~
- Dispatch the attach message as if it were received normally
- Continue execution from there
There will then either be a registration for a Terminal UX to take over the session by using ConPTY, ~~or the updated console will choose to launch its potentially updated version of the `conhost` UX~~.
For registration, we repeat the dance above with another key:
- A registry key in `HKCU\Console\%%Startup` (format `REG_SZ`, name `DelegationTerminal`).
The delegation repeats the same dance as above as well:
- A contract (interface) is established between the updated console and the terminal
-`HANDLE in`: The handle to read client application output from the ConPTY and display on the Terminal
-`HANDLE out`: The handle to write user input from the Terminal to the ConPTY
-`HANDLE signal`: The signal handle for the ConPTY for out-of-band communication between PTY server and Terminal application
- ~~`COORD size`: The initial window size from the starting application, as it can be a preference in the connection structure. (A resize message may get sent back downward almost immediately from the Terminal as its dimensions could be different.)~~ **V1 NOTE:** This proved unnecessary as the resize operations sorted themselves out naturally.
-`HANDLE ref`: This is a "client reference handle" to the console driver and session. We hold onto a copy of this in the Terminal so the session will stay alive until we let go. (The other console hosts in the chain also hold one of these, as should the client.)
-`HANDLE server`: This is a process handle to the PTY we're attached to. We monitor this to know when the PTY is still alive from the Terminal side.
-`HANDLE client`: This is a process handle to the underlying client application. The terminal tracks this for exit handling.
- **Alternative:** This should likely just be a COM server/client contract as well. This would be consistent with the above and wouldn't require argument parsing or wink/nudge understanding of standard handle passing. It also conveys the same COM flexibility as described in the inbox console section. **V1 NOTE:** We used this alternative. We used COM, not a well-known exported function from the prototype.
- The contract is called and on success, responsibility of the UX is given over to the Terminal. The console sits in PTY mode.
- On failure, the console launches interactive.
#### Terminal UX
The terminal will be its own complete presentation and input solution on top of a ConPTY connection, separating the concerns between API servicing and the user experience.
Today the Terminal knows how to start and then launches a ConPTY under it. The Terminal will need to be updated to accept a pre-existing ConPTY connection on launch (or when the multi-process model arrives, as an inbound connection), and connect that to a new tab/pane instead of using the `winconpty.lib` libraries to make its own.
For now, I'm considering only the fresh-start scenario.
- The Terminal will have to detect the inbound connection through ~~its argument parsing (or through~~ a new entrypoint in the COM alternative ~~)~~ and store the PTY in/out/signal handles for that connection in the startup arguments information
- When the control is instantiated on a new tab, that initial creation where normally the "default profile" is launched will instead have to place the PTY in/out/signal handles already received into the `ConPtyConnection` object and use that as if it was already created.
- The Terminal can then let things run normally and the connection will come through and be hosted inside the session.
There are several issues/concerns:
- Which profile/settings get loaded? We don't really know anything about the client that is coming in already-established. That makes it difficult to know what user preferences to apply to the inbound tab. We could:
- Use only the defaults for the incoming connection. Do not apply any profile-specific settings.
- Use the profile information from the default profile to some degree. This could cause some weird scenarios/mismatches if that profile has a particular icon or a color scheme that makes it recognizable to the user.
- Create some sort of "inbound profile" profile that is used for incoming connections
- Add a heuristic that attempts to match the name/path of the connecting client binary to a profile that exists and use those settings, falling back if one is not found.
- **Proposal:** Do the first one immediately for bootstrapping, then investigate the others as a revision going forward.
- The handles that are coming in are "raw" and "unpacked", not in the nice opaque `HPCON` structure that is usually provided to the `ConPtyConnection` object by the `winconpty.lib`.
- Add methods to `winconpty.lib` that allow for the packing of incoming raw handles into the `HPCON` structure so the rest of the lifetime can be treated the same
- Put the entrypoint for the COM server (or delegate the entrypoint for an argument) directly into this library so it can pack them up right away and hand of a ready-made `HPCON`.
## UI/UX Design
The user experience for this feature overall should be:
1. The user launches a command-line client application through the Start Menu, Win+X menu, the Windows Explorer, the Run Dialog box (WinKey+R), or through another existing Windows application.
1. Using the established settings, the console system transparently starts, delegates itself to the updated console, switches itself into ConPTY mode, and a copy of Windows Terminal launches with the first tab open to host the command-line client application.
- **NOTE:** I'm not precluding 3rd party registrations of either the delegation updated console nor the delegation terminal. It is our intention to allow either or both of these pieces to be replaced to the user's desires. The example is for brevity of our golden path and motivation for this scenario.
1. The user is able to interact with the command-line client application as they would with the original console host.
- The user receives the additional benefit that short-running executions of a command-line application may not "blink in and disappear" as they do today when a user runs something like `ipconfig` from the run dialog. The Terminal's default states tend to leave the tab open and say that the client has exited. This would allow a Run Dialog `ipconfig` user an improved experience over the default console host state of disappearing quickly.
1. If any portion of the delegation fails, we will progressively degrade back to a `conhost` style Win32+GDI UX and nothing will be different from before.
The settings experience includes:
- Configuration of the delegation operations:
- Locations:
- With the registry
- This is what's going to be available first and will remain available. We will progress to some or all of the below after.
- We will need to potentially add specifications to this to both the default profile (for new installations of Windows) or to upgrade/migration profiles (for users coming from previous editions of Windows) to enable the delegation process, especially if we put a copy of Windows Terminal directly into the box.
- **V1 NOTE:** we didn't add additional migration logic here as `HKCU\Console*` and subkeys were already in the migration logic, so adding another should just carry along.
- Inside Windows Terminal
- Inside the new Settings UI, we will likely need a page that configures the delegation keys in `HKCU\Console\%%Startup`~~or a link out to the Windows Settings panel, should we manage to get the settings configurable there~~.
- Inside the console property sheet
- Same as for Terminal but with `comctl` controls over XAML +/- a link to the Windows Settings panel
- Inside the Settings panel for Windows (probably on the developer settings page)
- The ultimate location for this is likely a panel directly inside Windows. This is the hardest one to accomplish because of the timelines of the Windows product. We may not get this in an initial revision, but it should likely be our ultimate goal. **V1 NOTE:** We did it!
- Operation:
- Specify paths/server IDs - This is the initial revision
- Offer a list of registered servers or discovered manifests from the app catalog - This is the ideal scenario where we search the installed app catalog +/- the COM catalog and offer a list of apps that conform to the contract in a drop-down.
- The final process was to use [App Extensions](https://docs.microsoft.com/windows/uwp/launch-resume/how-to-create-an-extension) inside the Terminal APPX package to declare the COM GUIDs that were available for the `DelegationConsole` and `DelegationTerminal` fields respectively. A configuration class `DelegationConfig` was added to `propslib.lib` that enables the lookup of these from the application state catalog and presents a list of them to choose from. It also manages reading and writing the registry keys.
- **V1 NOTE:** Our configuration options currently allow pairings of replacement consoles and terminals to be adjusted in lock-step from the UI. That's not to say further combinations are not possible or even necessarily inhibited by the code. We just went for minimal confusion in our first round.
- Configuration of the legacy console state:
- ~~Since we could end up in an experience where the default launch experience gets you directly into Windows Terminal, we believe that the Terminal will likely need an additional setting or settings in the new Settings UI that will allow the toggling of some of the `HKCU\Console` values to do things like set/remove the legacy console state.~~ **V1 NOTE:** Cut as low priority. Switch back to console and configure it that way or use the existing property sheet or tamper with registry keys.
- We have left the per-launch debugging and advanced access hole of calling something like `conhost.exe cmd.exe` which will use the inbox conhost to launch `cmd.exe` even if there is a default specified.
Concerns:
- State separation policy for Windows. I believe `HKCU\Console` is already specified as a part of the "user state" that should be mutable and carried forward on OS Swap, especially as we have been improving the OS swap experience.
- Ability for installers/elevated scripts to stomp the Delegation keys
- This was a long time problem for default app registrations and was limited in our OS. Are we about to run down the same path?
- What is the alternative here? To use a protocol handler? To store this configuration state data with other protected state in a registry area that is mutable, but only ACL'd to the `SYSTEM` user like some other things in the Settings control panel?
- **V1 NOTE:** We set ourselves up for some future ACL thing with the subkey, but we otherwise haven't enforced anything at this time.
## Capabilities
### Accessibility
Accessibility applications are the most likely to resort to a method of spelunking the process tree or window handles to attempt to find content to read out. Presuming they have hardcoded rules for console-type applications, these algorithms could be surprised by the substitution of another terminal environment.
The major players here that I am considering are NVDA, JAWS, and Narrator. As far as I am aware, all of these applications attempt to drive their interactivity through UI Automation where possible. And we have worked with all of these applications in the past in improving their support for both `conhost.exe` and the Windows Terminal product. I have relatively high confidence that we will be able to work with them again to help update these assistive products to understand the new UI delegation, if necessary.
### Security
Let's hit the elephant in the room. "You plan on pulling a completely different binary inside the `conhost.exe` process and just... delegating all activity to it?" Yes.
(**V1 NOTE:** Well, it's out of proc now. But it is at the same privilege level as the original one thanks to the mechanics of COM.)
As far as I'm concerned, the `conhost.exe` that is started to host the command-line client application is running at the same integrity level as the client binary that is partially started and waiting for its server to be ready. This is the long-standing existing protection that we have from the Windows operating system. Anything running in the same integrity level is already expected to be able to tamper with anything else at the same integrity level. The delegated binary that we would be loading into our process space will also be at the same integrity level. Nothing really stops a malicious actor from launching that binary in any other way in the same integrity level as a part of the command-line client application's startup.
The mitigation here, if necessary, would be to use `WinVerifyTrust` to validate the certification path of the `OpenConsole.exe` binary to ensure that only one that is signed by Microsoft can be the substitute server host for the application. This doesn't stop third parties from redistributing our `OpenConsole.exe` off of GitHub if necessary with their products, but it would stop someone from introducing any random binary that met the signature interface of the delegation methods into `conhost.exe`. The only value I see this providing is stopping someone from being "tricked" into delegating their `conhost.exe` to another binary through the configuration methods we provide. It doesn't really stop someone (or an attacker) from taking ownership of the `conhost.exe` in System32 and replacing it directly. So this point might be moot. (It is expected that replacement of the System32 one is already protected, to some degree, by being owned by the SYSTEM account and requiring some measure of authority to replace.)
### Reliability
The change on its own may honestly improve reliability of the hosting system. The existing just-in-time startup of the console host application only had a single chance at initializing a user experience before it would give up and return that the command-line application could not be started.
However, there are now several phases in the startup process that will have the opportunity to make multiple attempts at multiple versions or applications to find a suitable host for the starting application before giving up.
One layer of this is where the `conhost.exe` baked into the operating system will be on the lookout for an `OpenConsole.exe` that will replace its server activities. The delegation binary loses a bit of reliability, theoretically, by the fact that loading another process during launch could have versioning/resolution/path/dependency issues, but it simultaneously offers us the opportunity for improved reliability by being able to service that binary quickly outside the Windows OS release cycle. Fixes can arrive in days instead of months to years.
Another layer of this is where either `conhost.exe` or the delegated `OpenConsole.exe` server will search for a terminal user experience host, like `WindowsTerminal.exe` or another registered first or third party host, and split the responsibility of hosting the session with that binary. Again, there's a theoretical reliability loss with the additional process launch/load, but there's much to be gained by reducing the scope of what each binary must accomplish. Removing the need to handle user interaction from `conhost.exe` or `OpenConsole.exe` and delegating those activities means there is less surface area running and less chance for a UX interaction to interfere with API call servicing and vice versa. And again, having the delegation to external components means that they can be fixed on a timeline of days instead of months or years as when baked into the operating system.
### Compatibility
One particular scenario that this could break is an application that makes use of spelunking the process tree when a command-line application starts to identify the hosting terminal application window by HWND to inject input, extract output, or otherwise hook and bind to hosting services. As the default application UI that will launch may not have the `conhost.exe` name (for spelunking via searching processes) and the HWND located may either be the ConPTY fake HWND or an HWND belonging to a completely different UI, these applications might not work.
Two considerations here:
1. At a minimum, we must offer an opt-out of the delegation to another terminal for the default application.
1. We may also want to offer a process-name, policy, manifest, or other per client application opt-out mechanism.
**V1 NOTE:** There is no per-client specific way of doing this. The toggle is per-user and can be adjusted in 3 different places.
### Performance, Power, and Efficiency
I expect to take some degree of performance, power, and efficiency hit by implementing this replacement default app scenario just by it's nature. We will be loading multiple processes, performing tests and branches during startup, and we will likely need to load COM/WinRT and packaging data that was not loaded prior to resolve the final state of default application load. I would expect this to accrue to some failures in the performance and power gates inside the Windows product. Additionally, the efficiency of running pretty much everything through the ConPTY is lower than just rendering it directly to `conhost.exe`'s embedded GDI-powered UI itself thanks to the multiple levels of translation and parsing that occur in this scenario.
The mitigations to these losses are as follows:
1. We will delay load any of the interface load and packaging data lookup libraries to only be pulled into process space should we determine that the application is non-interactive.
1. That should save us some of the commit and power costs for the sorts of non-interactive scripts and applications that typically run early in OS startup (and leverage `conhost.exe` as their host environment).
1. We will still likely get hit with the on-disk commit cost for the additional export libraries linked as well as additional code. That would be a by-design change.
1. We plan to begin Profile Guided Optimization across our `OpenConsole.exe` and `WindowsTerminal.exe` binaries. This should allow us to optimize the startup paths for this scenario and bias the `OpenConsole.exe` binary that we redistribute to focus its efforts and efficiency on the ConPTY role specifically, ignoring all of the interactive Win32/GDI portions that aren't typically used.
1. We may need to add a PGO scenario inside Windows to tune the optimization of `conhost.exe` especially if we're going to go full on Windows Terminal in the box default application. The existing PGO that occurs in the optimization branches is running on several `conhost.exe` interactive scenarios, none of which will be relevant here. We would probably want to update it to focus on the default app delegation routine AND on the non-interactive scenario for hosted applications (where delegation will not occur but Win32/GDI will still not be involved).
## Potential Issues
### Passing Handles with COM
COM doesn't inherently expose a way for us to pass handles directly between processes with the existing contracts. We know this is possible because Windows does it all the time, but it doesn't appear to be public. We believe the mission forward is to expose this functionality to the public as if it's good enough for us internally and it is a requirement to build complex functionality like this... then it should be good enough for the public.
**V1 NOTE:** We gained approval to open this up and documented it. [`system_handle` attribute](https://docs.microsoft.com/windows/win32/midl/system-handle). It didn't require any code changes because the public IDL compiler already recognized the existence of this attribute and did the correct thing. It just wasn't documented for use.
## Future considerations
* We additionally would like to leave the door open to distributing updated `OpenConsole.exe`s in their own app package as a dependency that others could rely on.
* This was one of the original management requests when we were opening the source of the console product as well as the Terminal back in spring of 2019. For the sake of ongoing servicing and maintainability, it was requested that we reach a point where our dependencies could be serviced potentially independently of the product as a whole static unit. We didn't achieve that goal initially, but this design would enable us to do something like this.
* One negative to this scenario is that dependency resolution and the installation of dependent packages through APPX is currently lacking in several ways. It's difficult/impossible to do in environments where the store or the internet is unavailable. And it's a problem often enough that the Windows Terminal package embeds the VC runtimes inside itself instead of relying on the dependency resolution of the app platform.
## Resources
- [Windows Terminal Process Model 2.0 spec](https://github.com/microsoft/terminal/pull/7240)
- [Windows Terminal 2.0 Process Model Improvements](https://github.com/microsoft/terminal/issues/5000)
@@ -124,7 +124,7 @@ There's a few areas to study here.
#### Communicating the launch
For the parameters passing, I see a few options:
1.`conhost.exe` can look up the package registration for `wt.exe` and call an entrypoint with arguments. This could be adapted to instead look up which package is registered as the default one instead of `wt.exe` for third party hosts. We would have to build provisions into the OS to select this, or use some sort of publically documented registry key mechanism. Somewhat gross.
1.`conhost.exe` can look up the package registration for `wt.exe` and call an entrypoint with arguments. This could be adapted to instead look up which package is registered as the default one instead of `wt.exe` for third party hosts. We would have to build provisions into the OS to select this, or use some sort of publicly documented registry key mechanism. Somewhat gross.
1.`conhost.exe` can call the execution alias with parameters. WSL distro launchers use this.
1. We can define a protocol handler for these sorts of connections and let `wt.exe` register for it. Protocol handlers are already well supported and understood both by classic applications and by packaged/modern applications on Windows. They must have provisions to communicate at least some semblance of argument data as well. This is the route I'd probably prefer. `ms-term://incoming/<session-id>` or something like that. The receiving `wt.exe` can contact the manager process (or set one up if it is the first) and negotiate receiving the session that was specified into a new tab.
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
