Interesting things we could do after this:
- remove all `InitializeComponent` calls - they do it automatically
- have some Clang support (!)
- use `std::optional`<->`IReference` automatic binding
- use `std::format` support (!) for json/uri/hostname/http stuff/all
`IStringable`s
- potentially move to `/await:strict` for C++20 coroutines
I've also fixed up a couple ambiguities introduced by this change.
* `lld-link` is more strict about the casing of keywords in `.def` files
* `[[nodiscard]]` must come before `virtual` and `static` qualifiers
* `precomp.h` is never to be included with `<>`
* We were calling the jsoncpp constructors directly (oops) as functions
(oops)
* ClipboardTests constructed `KeyEvent`s by copy instead of directly
* While we can `await` a `Dispatcher`, it's clearer to add `resume_foreground`
#13626 contains a small "regression" compared to #13321:
It now began to store trailers in the buffer wherever possible to allow
a region
of the buffer to be backed up and restored via Read/WriteConsoleOutput.
But we're unfortunately still ill-equipped to handle anything but UCS-2
via
WriteConsoleOutput, so it's best to again ignore trailers just like in
#13321.
## Validation Steps Performed
* Added unit test ✅
This commit makes the following project-wide changes/replacements as a
first step in cleaning up our use of `NTSTATUS`.
* Rewriting any uses of `NTSTATUS_FROM_WIN32` that were vulnerable to multiple evaluation bugs
* This is required because the macro version of `NTSTATUS_FROM_WIN32` evaluates its argument twice
* Removing all our local redefinitions of `NTSTATUS` in favor of that of `winternl.h`
* Because of this, we got to (had to?) remove some old transclusions from `conddkrefs.h`
* `NT_SUCCESS` (ours) -> `SUCCEEDED_NTSTATUS` (wil)
* `VERIFY_IS_TRUE(NT_SUCCESS())` (overly elaborate) -> `VERIFY_NT_SUCCESS` (WEX)
* `VERIFY_SUCCESS_NTSTATUS` (ours) -> `VERIFY_NT_SUCCESS` (WEX)
* `!SUCCEEDED_NTSTATUS` -> `FAILED_NTSTATUS`
* One bad use of S_OK as an NTSTATUS -> `STATUS_SUCCESS`
* Removing `NTSTATUS` from any projects that do not use it
Does what it says in the title. After this commit you can customize the height
and width of the terminal's cells. This commit supports parts of CSS'
`<length-percentage>` data type: Font-size relative sizes as multiples (`1.2`),
percentage (`120%`), or advance-width relative (`1.2ch`), as well as absolute
sizes in CSS pixels (`px`) or points (`pt`).
This PR is neither bug free in DxEngine, nor in AtlasEngine.
The former fails to implement glyph advance corrections (for instance #9381),
as well as disallowing glyphs to overlap rows. The latter has the same
overlap issue, but more severely as it tries to shrink glyphs to fit in.
Closes#3498Closes#14068
## Validation Steps Performed
* Setting `height` to `1` creates 12pt tall rows ✅
* Setting `height` to `1ch` creates square cells ✅
* Setting `width` to `1` creates square cells ✅
* Setting `width` or `height` to `Npx` or `Npt` works ✅
* Trailing zeroes are trimmed properly during serialization ✅
* Patching the PR to allow >100 line heights and entering "100.123456"
displays 6 fractional digits ✅
## Summary of the Pull Request
Let the profile pages' views have access to the window root, rather than the `ProfileViewModel`. The window root is passed along when the page is navigated to.
## Validation Steps Performed
Clicking `Browse` no longer crashes.
## PR Checklist
- [x] Closes#14808
This pull request removes, in full, our dependency on cpprestsdk. This
allows us to shed 500KiB-1.2MiB from our package off the top and enables
the following future investments:
- Removal of the App CRT forwarders to save an additional ~500KiB
- Switching over to the HybridCRT and removing our dependency on _any
CRT_.
cpprest was built on my dev box two or so years ago, and is in _utter_
violation of our compliance guidelines on SBOM et al.
In addition, this change allows us to use the proxy server configured
in Windows Settings.
I did this in four steps (represented roughly by the individual commits):
1. Switch from cpprest's http_client/json to Windows.Web.Http and
Windows.Data.Json
2. Switch from websocketpp to winhttp.dll's WebSocket implementation¹
3. Remove all remaining utility classes
4. Purge all dependencies from all projects and scripts on cpprest.
I also took this opportunity to add a feature flag that allows Dev
builds to run AzureConnection in-process.
¹ Windows.Networking.Sockets' API is so unergonomic that it was simply
infeasible (and also _horrible_) to use it.
## Validation Steps
I've run the Azure Connection quite a bit inproc.
Closes#4575.
Might be related to #5977, #11714, and with the user agent thing maybe #14403.
This is a rather trivial changeset. Now that these two are present in the
`std` namespace there's no reason for us to continue using the `gsl` ones.
Additionally this ensures future compatibility with other 3rd party libraries.
When working on #14745 I noticed that `SplitToOem` was in a bit of a poor state
as well. Instead of simply iterating over its `deque` argument and writing the
results into a new `deque` it used `pop` to advance the head of both queues.
This isn't quite exception safe and rather bloaty. Additionally there's no need
to call `WideCharToMultiByte` twice on each character if we know that the most
verbose encoding is UTF-8 which can't be any more than 4 chars anyways.
Related to #8000.
## PR Checklist
* 2 unit tests cover this ✅
When working on #14745 I found `KeyEvent`s a little hard to read in the
debugger. I noticed that this is because of sign extension when converting
`char`s to `wchar_t`s in `KeyEvent::SetCharData`.
The original console output modes were considered attributes of the
buffer, while later additions were treated as global state, and yet both
were accessed via the same buffer-based API. This could result in the
reported modes being out of sync with the way the system was actually
behaving, and a call to `SetConsoleMode` without updating anything could
still trigger unpredictable changes in behavior.
This PR attempts to address that problem by making all modes part of the
buffer state, and giving them predictable default values.
While this won't solve all the tmux layout-breaking issues in #6987, it
does at least fix one case which was the result of an unexpected change
in the `DISABLE_NEWLINE_AUTO_RETURN` mode.
All access to the output modes is now done via the `OutputMode` field in
`SCREEN_INFORMATION`. The fields that were tracking global state in the
`Settings` class (`_fAutoReturnOnNewline` and `_fRenderGridWorldwide`)
have now been removed.
We still have a global `_dwVirtTermLevel` field, though, but that now
serves as a default value for the `ENABLE_VIRTUAL_TERMINAL_PROCESSING`
mode when creating a new buffer. It's enabled for conpty mode, and when
the VT level in the registry is not 0. That default doesn't change.
For the VT alternate buffer, things works slightly differently, since
there is an expectation that VT modes are global. So when creating an
alt buffer, we copy the current modes from the main buffer, and when
it's closed, we copy them back again.
## Validation Steps Performed
I've manually confirmed that this fixes the problem described in issue
#14690. I've also added a basic feature test that confirms the modes are
initialized as expected when creating new buffers, and changes to the
modes in one buffer do not impact any other buffers.
Closes#14690
New-TerminalStackedChangelog used to generate logs that looked like this:
```
* [3] A commit that was seen 3 times
* A commit that was only seen once
* [2] Some other commit
```
Now it will generate logs that look like this:
```
/ base..branch-1
|/ base..branch-2
||/ base..branch-3
* [XXX] A commit that was seen 3 times
* [ X ] A commit that was only seen once
* [XX ] Some other commit
```
This format is more expressive, as it indicates _which branches_ contain which commits.
As a reminder, my release note writing style starts with a stacked changelog. It's how I tell (1) which commits are in the new preview release only, (2) which commits are in the new preview and the new stable release and (3) which commits were already released in a previous stable release.
Changes from 1 get included in the new changelog, changes from 2 get included in both and changes from 3 get deleted because they have already been released.
For some reason, Windows Terminal stops dispatching UIA TextChanged events sometimes. There isn't a reliable repro for this bug.
However, under NVDA's logger, it appears that when the bug does occur, we still dispatch UIA notifications (which may be ignored by NVDA in some configurations). A "quick fix" here is to dispatch a TextChanged event if we're going to dispatch a notification. Since we're just enabling a flag, we won't send two events at once.
Closes#10911
The `SignalTextChanged` crash seems to be occurring due to the `TermControlAutomationPeer` being destructed by the time the UIA event is actually dispatched. Even though we're already checking if TCAP and TermControl still exist, it could be that the TermControl is being closed as text is being output.
The proposed fix here is to record when the closing process starts and exposing that information directly to the TCAP. If TCAP sees that we're in the process of closing, don't bother sending a UIA event.
Closes#13978
Up until now, we have been relying on the catalog signature produced for our MSIX package.
There are some things (Packaged COM, Process Explorer as of 2022) that cannot handle catalog-signed
files. It's easier and safer for us to simply sign all the executables we produce before packaging them.
Unfortunately, we can't do it before we package them. We have to unpack and re-pack our package.
In the future, this will allow us to provide a codesigned distribution that is not in an MSIX package.
TEST=Ran a build and checked out the contents of the package. They were all signed!
Closes#13294Closes#12695Closes#9670
We forgot to updateTheme again when we change the titlebar color. That would result in us setting the titlebar visibility only when the settings were reloaded, but if the unfocused BG was opaque, and the focused was transparent, we'd use the current _unfocused_ color to set the titlebar visibility.
Also, this fixes a bug with `tabRow.BG: terminalBackground`
from teams for brevity
> tabRow.BG = terminalBackground might not work, and here's why
>
> the termcontrol's BG brush might be (r,g,b, 255), with an Opacity of 0
>
> so my "use mica when the brush's A is <1.0" doesn't work
>
closes#14563
This uses `shell:AppsFolder` to launch elevated instances of the app via
`ShellExecuteEx` and `runas` in elevate-shim.exe. The app to launch is
discovered via the `GetCurrentApplicationUserModelId` API.
e.g. `shell:AppsFolder\WindowsTerminalDev_8wekyb3d8bbwe!App`
This will fallback to launching `WindowsTerminal.exe` if it fails to
discover the app user model id to launch.
This also fixes a bug in elevate-shim where the first argument of
WinMain was lost (e.g. `new-tab`).
Curiously, `AppLogic::RunAsUwp()` is never called and
`AppLogic::IsUwp()` is always false when running debug builds locally
(e.g. WindowsTerminalDev). It's not clear if this is an artifact of
development packages or something else.
## Validation Steps Performed
Various manual debug/execution scenarios.
Verified the fallback path by running the unbundled app by extracting
the `CascadiaPackage_0.0.1.0_x64.msix` from the 'drop' build artifact.
Fixes#14501
This regressed when we implemented ColorSchemeViewModel in #13179.
This commit fixes that by automatically focusing the ColorSchemeListView
when we navigate to the ColorSchemes page, which makes sense from a
user experience perspective anyway.
Closes#11971
Specify the resource to use for the list view item background when selected.
References #14693
## Validation Steps Performed
Background is no longer blue, it is light gray (like in Windows 11). Screenshots below.
This should make sure we only use Mica for the BG of the SUI when we're on a Windows build that supports it. Otherwise, we're just gonna get the emergency backstop / full transparency under it.
Confirmed this fixes it on my win10 VM.
Closes#14667
This PR add support for the ANSI Insert/Replace mode (`IRM`), which
determines whether output characters are inserted at the active cursor
position, moving existing content to the right, or whether they should
overwrite the content that is already there.
The implementation is a bit of a hack. When that mode is enabled, it
first measures how many cells the string is expected to occupy, then
scrolls the target line right by that amount before writing out the new
text.
In the longer term it might be better if this was implemented entirely
in the `TextBuffer` itself, so the scrolling could take place at the
same time as the content was being written.
## Validation Steps Performed
I've added a very basic unit test that verifies the mode is working as
expected. But I've also done a lot more manual testing, confirming edge
cases like wide characters, double-width lines, and both with and
without wrapping mode enabled.
Closes#1947
## Summary of the Pull Request
When we navigate to the color schemes page, find the default color scheme (if present) and manually set the container's automation name to include the word 'default'.
Note that we don't want to change the actual `ColorSchemeViewModel`'s name since that name is used internally to identify schemes. We only want to change the `ListViewItem`'s name, i.e. the container in the SUI.
## PR Checklist
* [x] Closes#14401
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [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
## Validation Steps Performed
Screen reader reads out the 'default' text now. It also correctly reads out the new default scheme if the default scheme is changed via SUI or json.
As of about 2022, the one's digit of the Build of our version is a placeholder value to differentiate the Windows 10 build from the Windows 11 build. Let's trim that out, it's only a source of confusion.
For additional clarity, let's omit the Revision, which _must_ be `.0`, and doesn't provide any value to report.
We will need to make sure we report releases as `1.17.ABC` now, instead of `1.17.ABC1.0`/`1.17.ABC2.0`
Let's not backport this. 1.17 will be the start of the new numbering scheme. Otherwise, `1.16.EFG` < `1.16.ABC1.0`, for an old version `ABC1` and a new version `EFG`.
* closes#14106
* As summarized here: https://github.com/microsoft/terminal/issues/14106#issuecomment-1289462310
`_Entries` was getting default constructed to `nullptr`. We should be careful about that.
Adds a test too, and fixes a regression in the local tests introduced in #13763.
Closes#14557
ColorScheme MVVM was implemented in #13179. This PR updates the
ProfileViewModel/AppearanceViewModels to use color scheme view models
instead of the raw settings model objects.
* [x] Updates ProfileViewModel/AppearanceViewModel to use
ColorSchemesPageViewModel/ColorSchemeViewModel implemented in #13179
* [x] Removes ProfilePageNavigationState
## Validation Steps Performed
Settings UI still works (we _probably_ want to bug bash this at some
point though as with all SUI changes)
The main purpose of this PR was to merge the `ITerminalApi::PrintString`
implementations into a shared method in `AdaptDispatch`, and avoid the
VT code path depending on `WriteCharsLegacy`. But this refactoring has
also fixed some bugs that existed in the original implementations.
This helps to close the gap between the Conhost and Terminal (#13408).
I started by taking the `WriteCharsLegacy` implementation, and stripping
out everything that didn't apply to the VT code path. What was left was
a fairly simple loop with the following steps:
1. Check if _delayed wrap_ is set, and if so, move to the next line.
2. Write out as much of the string as will fit on the current line.
3. If we reach the end of the line, set the _delayed wrap_ flag again.
4. Repeat the loop until the entire string has been output.
But step 2 was a little more complicated than necessary because of its
legacy history. It was copying the string into a temporary buffer,
manually estimated how much of it would fit, and then passing on that
partial buffer to the `TextBuffer::Write` method.
In the new implementation, we just pass the entire string directly to
`TextBuffer::WriteLine`, and that handles the clipping itself. The
returned `OutputCellIterator` tells us how much of the string is left.
This approach fixes some issues with wide characters, and should also
cope better with future buffer enhancements.
Another improvement from the new implementation is that the Terminal now
handles delayed EOL wrap correctly. However, the downside of this is
that it introduced a cursor-dropping bug that previously only affected
conhost. I hadn't originally intended to fix that, but it became more of
an issue now.
The root cause was the fact that we called `cursor.StartDeferDrawing()`
before outputting the text, and this was something I had adopted in the
new implementation as well. But I've now removed that, and instead just
call `cursor.SetIsOn(false)`. This seems to avoid the cursor droppings,
and hopefully still has similar performance benefits.
The other thing worth mentioning is that I've eliminated some special
casing handling for the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` mode and
the `WC_DELAY_EOL_WRAP` flag in the `WriteCharsLegacy` function. They
were only used for VT output, so aren't needed here anymore.
## Validation Steps Performed
I've just been testing manually, writing out sample text both in ASCII
and with wide Unicode chars. I've made sure it wraps correctly when
exceeding the available space, but doesn't wrap when stopped at the last
column, and with `DECAWM` disabled, it doesn't wrap at all.
I've also confirmed that the test case from issue #12739 is now working
correctly, and the cursor no longer disappears in Windows Terminal when
writing to the last column (i.e. the delayed EOL wrap is working).
Closes#780Closes#6162Closes#6555Closes#12440Closes#12739
I can't exactly repro #14559. I suspect that's due to #14567 having been merged. This, however, seemed related. Without this, we'll use the App's `RequestedTheme` (the one that can't be changed at runtime), rather than the user's `requestedTheme`. That will do weird things, like make the BG of the SUI dark, with white expanders.
I think this should close#14559.
Some investigation revealed that `_keyEvents` would get a `NULL_POINTER_READ` error. On the main thread, `RecordKeyEvent()` would be called, which mainly updates `_keyEvents`. On the renderer thread, `NotifyNewOutput()` would be called, which starts by iterating through `_keyEvents` and slowly clearing it out. On occasion, these two threads are modifying `_keyEvents` simultaneously, causing a crash.
The fix is to add a mutex on this variable.
Closes#14592
Basically what it says on the tin. For transparent tabs, we should layer on to the tab row to evaluate what the actual color of the tab will be. We did this for deselected tabs, but not for selected ones.
Gif below.
Closes#14561
## Summary of the Pull Request
Updates the tab event handling so that the "Export Text" and "Find" tab context menu items work when a tab isn't focused.
## PR Checklist
* [x] Closes#13948
* [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 builds upon #10749. When we added a separate pivot to track the "active" anchor, we forgot to update the pivot while circling. What does that mean? Moving the mouse would trigger us to update the selection using new endpoint and the old _pivot_, which hadn't been updated.
There's probably a more elegant way of doing this, but it's good enough.
Updated the test to cover this as well.
Closes#14462
What it says on the tin.
I finally figured out the right way to validate schema updates in VsCode, which made this a lot faster. Tossed notes in the wiki for next time I do this.
Closes#14560
#14461 is caused by a null pointer exception in `TerminalIsSelectionActive()`. Since this reveals that it is possible to enter a state where `_terminal` is null, I've gone ahead and added null-checks throughout the code to make it more stable.
Closes#14461
## Validation Steps Performed
Ran locally. Still works.
CascadiaSettings relies on getting a JsonUtils::DeserializationException
from the various JSON Utility functions, and then formatting that into
an error message. Well, DeserializationException tries to include an
object representation in its what() message . . . and generates an
exception trying to do so. CascadiaSettings never gets the
DeserializationException, and displays a weird message.
It's safe to remove the stringification in DeserializationException
because CascadiaSettings was never using it (_and_ because
CascadiaSettings was using an even better version of the same logic.)
Fixes#14373
When the buffer contains wide characters that occupy more than one cell,
and those cells are scrolled horizontally by exactly one column, that
operation can result in the wide characters being completely erased.
This PR attempts to fix that bug, although it's not an ideal long term
solution.
Although not really to blame, it was PR #13626 that exposed this issue.
The root of the problem is that scrolling operations copy cells one by
one, but wide characters are written to the buffer two cells at a time.
So when you move a wide character one position to the left or right, it
can overwrite itself before it's finished copying, and the end result is
the whole character gets erased.
I've attempt to solve this by getting the affected operations to read
two cells in advance before they start writing, so there's no risk of
losing the source data before it's fully output. This may not work in
the long term, with characters wider than two cells, but it should at
least be good enough for now.
I've also changed the `TextBuffer::Write` call to a `WriteLine` call to
improve the handling of a wide character on the end of the line, where
moving it right by one column would place it half off screen. It should
just be dropped, but with the `Write` method, it would end up pushed
onto the following line.
## Validation Steps Performed
I've manually confirmed this fixes all the test cases described in
#14626, and also added some unit tests that replicate those scenarios.
Closes#14626
This is basically just like #14064, but with the `theme` instead.
If you define a pair of `theme` names:
```json
"theme": { "dark": "light", "light": "dark" },
```
then the Terminal will use the one relevant for the current OS theme. This cooperates with #14064, who sets the `scheme` based on the app's theme.
This was spec'd as a part of #3327 / #12530, but never promoted to its own issue.
Gif below.
In order to modify the accessibility information for the PseudoConsoleWindow, it needs to have a UIA provider registered. This PR introduces `PseudoConsoleWindowAccessibilityProvider` and registers it as a UIA provider appropriately. The registration process is based on that of the `WindowUiaProvider` for ConHost.
Closes#14385
## Validation Steps Performed
Run Accessibility Insights FastPass on the window. The PseudoConsoleWindow no longer is tagged as missing a name.
