Closes#17515
## Validation Steps Performed
* Disable the ASB while there's a pending cooked read
* Type some text
* No crash ✅
(cherry picked from commit dfcc8f3c6218b8d747bdd4bed6f7b6d1996bb376)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgdFoBM
Service-Version: 1.23
This PR resolves an issue where scrollbar marks created by shell
integration sequences (OSC 133 FTCS, OSC 1337 iTerm2, and OSC 9;12
ConEmu sequences) were not visible on the scrollbar until the user
manually scrolled.
The problem was that while marks were being created in the buffer
correctly, the UI wasn't being notified to refresh the scrollbar
display. The fix adds a new NotifyShellIntegrationMark() method to the
ITerminalApi interface that calls _NotifyScrollEvent() to trigger
scrollbar refresh, and updates all shell integration sequence handlers
in AdaptDispatch to call this notification method after creating marks.
This ensures scrollbar marks appear immediately when shell integration
sequences are processed, bringing feature parity between auto-detected
and shell-integration-based marks.
Closes#19104
(cherry picked from commit e818dafa6db29cb67cc2418ba67e5e0846a6e9b4)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgdFukU
Service-Version: 1.23
This PR fixes issue #7130 where WT_SESSION and WT_PROFILE_ID environment
variables were being duplicated in the WSLENV environment variable when
multiple terminal sessions were created.
The previous implementation always appended WT_SESSION:WT_PROFILE_ID: to
WSLENV without checking if these variables already existed, causing
duplication.
Closes#7130
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
(cherry picked from commit 7d6e0c8b8e499b24eb59e197f06bc9b82c6b9427)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgdDF2w
Service-Version: 1.23
## Summary of the Pull Request
Adds new telemetry events to track traffic through the new tab menu.
Specifically, the following events are added:
- `NewTabMenuDefaultButtonClicked`: Event emitted when the default
button from the new tab split button is invoked
- `NewTabMenuOpened`: Event emitted when the new tab menu is opened
- `NewTabMenuClosed`: Event emitted when the new tab menu is closed
- `NewTabMenuItemClicked`: Event emitted when an item from the new tab
menu is invoked
- Has an `ItemType` parameter that can be set to `Settings`,
`CommandPalette`, `About, `Profile`, `Action`
- Has a `TabCount` parameter that keeps tracked of the number of tabs in
the window before changing the state
- `NewTabMenuCreatedNewTerminalSession`: Event emitted when a new
terminal was created via the new tab menu
- Has a `SessionType` parameter that can be set to `ElevatedWindow`,
`Window`, `Pane`, `Tab`
- Instead of `TabCount`, has a `NewTabCount` that keeps track of the
_new_ number of tabs after the session has been created
- `NewTabMenuItemElevateSubmenuItemClicked`: Event emitted when the
elevate submenu item from the new tab menu is invoked
## Validation Steps Performed
Used TVPP to see events generated from interacting with the new tab
menu.
(cherry picked from commit 8c20d2052df20a6cb40b2f6d0e0b3d1dbbfb529b)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgc0Dws
Service-Version: 1.23
Disables a controversial part of #19044.
Refs #19075
(cherry picked from commit 7b841628dfd332dbd6e69a44dc1b85ec17ca5837)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgcqq7A
Service-Version: 1.23
If an IME provider sets both `crText` and `crBk` we should respect this,
but the previous logic would incorrectly assert for `crLine !=
TF_CT_NONE`.
## Validation Steps Performed
❌ I'm not aware which TSF even sets these colors in a
way that's compatible with us in the first place...
(cherry picked from commit f2b30b4e1e6b6555bddb5d3c9ff8f400d5ebe4b2)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgck4T0
Service-Version: 1.23
This will prevent Terminal from erroneously selecting a hidden (deleted,
disabled or otherwise) profile of the same name during restoration and
subsequently using the wrong settings.
I am not certain why we used the name at all!
Closes#19105
(cherry picked from commit c4fbb58f69b0a5cc86c245505311d0a0b3cc1399)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgcbMe0
Service-Version: 1.23
Right now, we do not use a sufficiently unique name to disambiguate
Terminal instances running on the same desktop.
Mutexes (mutants) are named objects that live in the user's session,
under `Sessions\1\BaseNamedObjects` (for the local desktop session).
When multiple users are logged into the same session--such as with "Run
as different user"--they share a local BaseNamedObjects namespace. Ugh.
We cannot use [`CreatePrivateNamespace`] as it requires a boundary
descriptor, and the only boundary descriptors supported by the current
API are based on package identity. I also fear that
`CreatePrivateNamespace` is subject to a race condition with
`OpenPrivateNamespace`; Create will not Open an existing one, so we
would need to back off and retry either opening or creating. Yuck.
After this commit, we will hash the user's SID into the name of both the
window class and the mutant, right after the path hash (if running
unpackaged).
Closes#18704
[`CreatePrivateNamespace`]:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprivatenamespacea
(cherry picked from commit 02f173d504d82a05da048981c56b7402c11b6c0c)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgYvcQw
Service-Version: 1.23
The crash occurs because WinRT `abort()`s when it encounters
a `std::wstring_view` without null-terminator.
Closes#19093
## Validation Steps Performed
* Set `wtd` as the default terminal
* Launch `cmd`
* Launch `wtd`
* 2 windows ✅
(cherry picked from commit ac07afebcb949687db8cadf60605f11ee804ec15)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgcO9T4
Service-Version: 1.23
This changes the ConPTY handoff COM server from `REGCLS_SINGLEUSE`
to `REGCLS_MULTIPLEUSE`. The former causes a race condition, because
handoff runs concurrently with the creation of WinUI windows.
This can then result in the a window getting the wrong handoff.
It then moves the "root" of ConPTY handoff from `TerminalPage`
(WindowEmperor -> AppHost -> TerminalWindow -> TerminalPage)
into `WindowEmperor` (WindowEmperor).
Closes#19049
## Validation Steps Performed
* Launching cmd from the Start Menu shows a "Command Prompt" tab ✅
* Win+R -> `cmd` creates windows in the foreground ✅
* Win+R -> `cmd /c start /max cmd` creates a fullscreen tab ✅
* This even works for multiple windows, unlike with Canary ✅
* Win+R -> `cmd /c start /min cmd` does not work ❌
* It also doesn't work in Canary, so it's not a bug in this PR ✅
(cherry picked from commit a25d968fe0026ac5abea62a67d798c89e1280d32)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgbpecU
Service-Version: 1.23
Introduces an ABI change to the ConptyClearPseudoConsole signal.
Otherwise, we have to make it so that the API call always retains
the row the cursor is on, but I feel like that makes it worse.
Closes#18732Closes#18878
## Validation Steps Performed
* Launch `ConsoleMonitor.exe`
* Create some text above & below the cursor in PowerShell
* Clear Buffer
* Buffer is cleared except for the cursor row ✅
* ...same in ConPTY ✅
(cherry picked from commit fc0a06c3b6cae2ede1326eef202a800244365ebd)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzga5M7E
Service-Version: 1.23
Fixes a crash when multiple panes were closed simultaneously (i.e. using
broadcast input).
The root cause of this crash was that we would get a null pointer
exception when trying to access a member/function off of a null
`_content`. This is because `Pane::_CloseChild()` would always pass over
the content from the non-closed pane and attempt to hook everything up
to it.
The fix was to operate similarly to `Pane::Close()` and raise a `Closed`
event and return early. Since there's no alternative content to attach
to, might as well just close the entire pane. This propagates up the
stack of listeners to update the UI appropriately and close the parent
pane and eventually the entire tab, if necessary.
Closes#18071Closes#17432
## Validation Steps Performed
1. Open 2 panes
2. Use broadcast input to send "exit" to both panes
3. ✅ Terminal doesn't crash and the tab closes gracefully
(cherry picked from commit 6bf315a4c904fbc01187e155a55117dfd7e7f893)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgb3LNk
Service-Version: 1.23
Adds logic to display a warning popup if the settings.json is marked as
read-only and we try to write to the settings.json file. Previously,
this scenario would crash, which definitely isn't right. However, a
simple fix of "not-crashing" wouldn't feel right either.
This leverages the existing infrastructure to display a warning dialog
when we failed to write to the settings file. The main annoyance here is
that that popup dialog is located in `TerminalWindow` and is normally
triggered from a failed `SettingsLoadEventArgs`. To get around this,
`CascadiaSettings::WriteSettingsToDisk()` now returns a boolean to
signal if the write was successful; whereas if it fails, a warning is
added to the settings object. If we fail to write to disk, the function
will return false and we'll raise an event with the settings' warnings
to `TerminalPage` which passes it along to `TerminalWindow`.
Additionally, this uses `IVectorView<SettingsLoadWarnings>` as opposed
to `IVector<SettingsLoadWarnings>` throughout the relevant code. It's
more correct as the list of warnings shouldn't be mutable and the
warnings from the `CascadiaSettings` object are retrieved in that
format.
- ✅ Using SUI, save settings when the settings.json is set to read-only
Closes#18913
(cherry picked from commit 218c9fbe3ecd79cc15d9cab267753b1b68ead250)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgb3QSk
Service-Version: 1.23
## Summary of the Pull Request
Adds branding and distribution metadata to the following telemetry
events:
- ActionDispatched (branding only)
- JsonSettingsChanged
- UISettingsChanged
- SessionBecameInteractive
Also removes the settings logger output from the debugger and some
leftover debugging functions.
Adds a label to the XSettingsChanged settings value to make it easier to
read on the backend.
(cherry picked from commit b50eaa19e0cfa396d40d2359c1b64e73e2d6af4f)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgaj8x4
Service-Version: 1.23
## Summary of the Pull Request
Some applications that make use of the `OSC 52` clipboard sequence will
only do so if they can be certain that the terminal actually has that
functionality. Indicating our support for `OSC 52` in the `DA1` report
will give them an easy way to detect that.
## References and Relevant Issues
`OSC 52` support was added to Windows Terminal in issue #5823, and to
ConHost in issue #18949.
## Detailed Description of the Pull Request / Additional comments
Support for writing to the clipboard is indicated in the primary device
attributes report by the extension parameter `52`. This is obviously not
a standard DEC extension, but it's one that's been agreed upon by a
number of modern terminals. The extension is only reported when writing
to the clipboard is actually permitted (Windows Terminal has an option
to disable that).
## Validation Steps Performed
I've updated the Device Attributes unit test to check that we're
reporting extension `52` when clipboard access is enabled, and not
reporting it when disabled.
## PR Checklist
- [x] Closes#19017
- [x] Tests added/passed
(cherry picked from commit 00ee88400aab0cd94409204ce0c6d20854ba7eff)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgbpe4g
Service-Version: 1.23
Right now, image validation accepts web-sourced icons (boo) and rejects
images whose paths begin with `\\?\`. In addition, it will warn the user
for things out of their control like images set by fragments.
This pull request adds a filesystem path validator (which accepts images
with fully-qualified paths and UNC paths), makes the URI validator
reject any web-origin URIs (only `file` and `ms-*` are allowable), and
suppresses warnings for any images that were not _directly_ set by the
user.
Since we want to avoid using fragment images that fail validation, we no
longer `Clear` each image property but rather set it to the blank or
fallback value.
This does **not** actually add support for images at absolute paths
beginning with `\\?\`. Such images are still rejected by `Image` and the
other XAML fixtures we use for images. It's better than a warning,
though.
Closes#18703Closes#14143
Refs #18710
Refs #5204
Related to #18922 (http-origin icons will be blank everywhere and not
just the jump list ;))
(cherry picked from commit f28bb42979756318073a9d42b0209e6f9ebd77c7)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgbjZlM
Service-Version: 1.23
* Make PowerShell profile generation try to find `pwsh.exe` before
falling back to legacy powershell
* Make profiles generated on an `arm64` host work properly
## Validation Steps Performed
* Local build ran
* Verified the new `arm64` profile works
* Verified `pwsh.exe` is used if present
* Verified `powershell.exe` is used if `pwsh` is not present in path
* Verified we don't attempt to create `arm64` host cmd/pwsh profiles if
VS is not >= 17.4
(cherry picked from commit bb62ce93459feb9bbe0a90ddb6c444bc23817d20)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgbeRwg
Service-Version: 1.23
I can't explain this, but VS 17.14 ships with VisualCpp.Tools.Core
version 14.44.35208 but the files say 14.44.35207.
(cherry picked from commit 9dbcf4b9dd33d36ac0145db195db7563f5a86c05)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgbDfzM
Service-Version: 1.23
Looks like there's a new VS version on the build agents. This just goes
through and fixes any issues they found.
There's still a COMPILER CRASH though.
(cherry picked from commit 2d64a3a4ab0d0d1c5b9085a022f5319460ef68d7)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgakG1s
Service-Version: 1.23
Once an application has returned from handling `WM_ENDSESSION`
the OS may kill the app at any point. This means we must
persist our state while inside the message handler.
Closes#17179
Honestly, none. It's a race condition in the first place.
(cherry picked from commit 26cd15a14b0bfc06a951c800d960336328176173)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaZoI8
Service-Version: 1.23
When the cursor is over the non-client area it wouldn't
show the cursor when moving it. Now it works as expected.
(cherry picked from commit 4d094df5080dcf9e58aa76e8a255ca6ace0ddf60)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaZJvk
Service-Version: 1.23
I finally realized the missing piece.
We need to clear the state array unconditionally,
as otherwise it won't get cleared. Duh.
Closes#18584
## Validation Steps Performed
* Craft a state.json with a layout
* Launch Terminal while the feature is disabled
* state.json is cleaned up on exit ✅
(cherry picked from commit 69fc2d94ee7a138e71fc7a4c2e2f045f3ee628c8)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaZGpY
Service-Version: 1.23
They're much prettier, but some users may not be 100% happy.
(cherry picked from commit 696dac2c6a29ec83fa96247ca19cb0e2c8a31da0)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaWoFc
Service-Version: 1.23
We never hooked up this callback!
This allows a CLI application to emit text directly to the clipboard.
(cherry picked from commit c64a9d2a32402455d196edacd7f5ac92ddaf508f)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaWn6c
Service-Version: 1.23
Went through the settings UI and checked which other setting containers
were missing a preview. Here's the list:
- starting directory
- tab title
- background image
- answerback message
- bell style
Adding them was fairly straightforward. Tried to reuse existing
resources when possible. The general pattern was to add a
"Current<Setting>" or "<Setting>Preview" getter that just created the
human-readable format of the setting.
## Validation Steps Performed
✅ value is shown (including special values!)
✅ each of these work with a screen reader
Closes#18576
(cherry picked from commit 7359df0382189ca2194236879eff24b12f7740ff)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaWgOw
Service-Version: 1.23
The `SGR 1` VT attribute can either be interpreted as a brighter color,
or as a bolder font, depending on the _Intense text style_ setting.
However, the concept of brightness only applies to the eight standard
ANSI colors, so when `SGR 1` is configured as _bright_, it has no effect
on the ITU T.416 colors (RGB and the 256 index colors).
To address that, we now interpret `SGR 1` as a bolder font when applied
to ITU colors, regardless of whether the _Intense text style_ option is
set to bold or not.
Note that this only applies to the Atlas render engine, since the GDI
engine doesn't support bold fonts.
## Validation Steps Performed
I've manually tested `SGR 1` applied to different color formats with the
_Intense text style_ option set to _None_, and confirmed that the text
is now rendered with a bold font for ITU colors, but not for ANSI/AIX
colors.
Closes#18284
(cherry picked from commit 07c9a99273f998e3c758324b4d038cf5532bc302)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaWKqk
Service-Version: 1.23
This fixes#18877, by iteratively checking to see if a line is wrapped
and moving up or down accordingly.
**Current behavior:** When a user triple-clicks on a line that’s
visually wrapped by the terminal, only the single physical row that was
clicked gets selected.
**Expected behavior:** A triple-click like in xterm, should select the
entire logical line including all of its wrapped segments, from the true
start through its true end, regardless of where the wrap occurred.
**Why it matters:** Logical line selection is what users expect when
they’re trying to grab one command or output block in full. Limiting the
selection to just the current physical row can lead to copy/paste
mistakes and a confusing experience whenever a long line wraps.
## Validation Steps Performed
I ran the existing tests using `Invoke-OpenConsoleTests` and they were
passing and I was also able to test the build on my machine. I added a
test case as well
## PR Checklist
Closes#18877
(cherry picked from commit 976a54d87cba22e21e83c7f719c516ec84bfc41e)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaHgMU PVTI_lADOAF3p4s4AxadtzgaMvXs
Service-Version: 1.23
We ship the org chart, baby!
(cherry picked from commit f08321a0b24bd6870c2f868e19e7565193b615a1)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgaT5FU
Service-Version: 1.23
This fixes two issues in the WPF terminal control:
- The emoji picker and other IME candidate windows didn't show up in the
right place
- Submitting an emoji via the emoji picker would result in two win32
input mode events with a VK of 65535 and the surrogate pair halves.
I am not sure I did the right thing with the thread TSF handle...
(cherry picked from commit 06f736bebe84eda0c34b935a875eebe031a899b7)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZ-Sw0
Service-Version: 1.23
According to the documentation, the final character of an SGR mouse
report is meant to be `M` for a button press and `m` for a button
release. However it isn't clear what the final character should be for
motion events, and we were using an `m` if there weren't any buttons
held down at the time, while all other terminals used an `M`, regardless
of the button state.
This PR updates our implementation to match what everyone else is doing,
since our interpretation of the spec was causing problems for some apps.
## Validation Steps Performed
I've manually tested the new behavior in Vttest, and confirmed that our
mouse reports now match Xterm more closely, and I've tested with v0.42.0
of Zellij, which was previous glitching badly in Windows Terminal, but
now works correctly.
I've also updated our unit tests for the SGR mouse mode to reflect the
correct report format.
Closes#18712
(cherry picked from commit 865f5e52397025cfb21f40871bfaf04d85a44986)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZ9_Ew
Service-Version: 1.23
This PR fixes two cases where image content wasn't correctly erased when
overwritten.
1. When legacy console APIs fill an area of the buffer using a starting
coordinate and a length, the affected area could potentially wrap over
multiple rows, but we were only erasing the overwritten image content on
the first affected row.
2. When copying an area of the buffer with text content over another
area that contained image content, the image in the target area would
sometimes not be erased, because we ignored the `_eraseCells` return
value which indicated that the image slice needed to be removed.
## References and Relevant Issues
The original code was from the Sixel implementation in PR #17421.
## Validation Steps Performed
I've manually verified that these two cases are now working as expected.
## PR Checklist
- [x] Closes#18568
(cherry picked from commit 08e76da3a1687a1303733406b684a9a6ab523acb)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZ3XT4
Service-Version: 1.23
This requires us to delay-sign the assembly with a public key (the snk
file), and then later submit it for strong naming. This is separate from
code signing, and has to take place before it.
The snk file does not contain any private key material.
This cannot merge until we are approved to use this new signing "key
code".
(cherry picked from commit 0568173abab4150d167dcced3994c99356dfc5cd)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZuEzU
Service-Version: 1.23
I've been doing this manually. It is time for me to do it not-manually.
(cherry picked from commit 21f31793263d411c17ae676855f431b357211b64)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZwVgg
Service-Version: 1.23
This required removing connections during the build to `nuget.org` and
`powershellgallery.com`.
The NuGet Tool task was downloading nuget from `nuget.org`
unconditionally.
The `AzureFileCopy` task was downloading `Az.Accounts` from
`powershellgallery.com` unconditionally.
Both of these tasks have better options nowadays.
Tested and passed in OneBranch on 2025-04-01.
(cherry picked from commit 22c509f426a7d2cdf616bc18143f5bc24f238c4f)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZ0dVQ
Service-Version: 1.23
When Sixel images are rendered, they're automatically scaled to match
the 10x20 cell size of the original hardware terminals. If this requires
the image to be scaled down, the default GDI stretching mode can produce
ugly visual artefacts, particularly for color images. This PR changes
the stretching mode to `COLORONCOLOR`, which looks considerably better,
but without impacting performance.
The initial Sixel implementation was added in PR #17421.
## Validation Steps Performed
I've tested with a number of different images using a small font size to
trigger the downscaling, and I think the results are generally better,
although simple black on white images are still better with the default
mode (i.e. `BLACKONWHITE`), which is understandable.
I've also checked the performance with a variation of the [sixel-bench]
test, and confirmed that the new mode is no worse than the default.
[sixel-bench]: https://github.com/jerch/sixel-bench
(cherry picked from commit b243fb6189238b7549aea18cf54b58243c01ff6e)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZ0dHA
Service-Version: 1.23
We used to cherry-pick every commit that had even one card in "To Cherry
Pick", even if it was also referenced by a card in "Rejected" or even
"To Consider".
Now we will warn and skip those commits.
I took this opportunity to add a bit of an object model for servicing
cards as well as prettify the output.
That allowed us to add a list of cards that were ignored due to having
no commits, and display little icons for each type of card.
(cherry picked from commit 8e94983170db5251182f6d2e09390c786f7e7969)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZtpq8
Service-Version: 1.23
The conhost v2 rewrite from a decade ago introduced a race condition:
Previously, we would acquire and hold the global console lock while
servicing
a console API call. If the call cannot be completed a wait task is
enqueued,
while the lock is held. The v2 rewrite then split the project up into a
"server" and "host" component (which remain to this day). The "host"
would
hold the console lock, while the "server" was responsible for enqueueing
wait
tasks _outside of the console lock_. Without any form of
synchronization,
any operations on the waiter list would then of course introduce a race
condition. In conhost this primarily meant keyboard/mouse input, because
that
runs on the separate Win32 window thread. For Windows Terminal it
primarily
meant the VT input thread.
I do not know why this issue is so extremely noticeable specifically
when we
respond to DSC CPR requests, but I'm also not surprised: I suspect that
the
overall performance issues that conhost had for a long time, meant that
most
things it did were slower than allocating the wait task.
Now that both conhost and Windows Terminal became orders of magnitudes
faster
over the last few years, it probably just so happens that the DSC CPR
request
takes almost exactly as many cycles to complete as allocating the wait
task
does, hence perfectly reproducing the race condition.
There's also a slight chance that this is actually a regression from my
ConPTY
rewrite #17510, but I fail to see what that would be. Regardless of
that,
I'm 100% certain though, that this is a bug that has existed in v0.1.
Closes#18117Closes#18800
## Validation Steps Performed
* See repro in #18800. In other words:
* Continuously emit DSC CPR sequences
* ...read the response from stdin
* ...and print the response to stdout
* Doesn't deadlock randomly anymore ✅
* Feature & Unit tests ✅
(cherry picked from commit 29924217615d58940d8309bec49476fa9dd2fb6b)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZiUlo
Service-Version: 1.23
The "open JSON" button in the settings UI wasn't working when invoked
via accessibility tools (specifically Narrator in scan mode and Voice
Access). For some reason, in those scenarios, neither the `Tapped` or
`KeyDown` event were hit!
This PR adds the logic to open the json file via the `ItemInvoked` event
instead. The `Tapped` and `KeyDown` handlers were removed to prevent a
redundant `OpenJson` event being raised.
Additionally, `SelectsOnInvoked` was set to `False` on the "open JSON"
nav item. This prevents the selection pill from moving to the nav item,
which feels more correct.
## Validation Steps Performed
The following scenarios are confirmed to open the JSON
✅ Mouse click
✅ Keyboard (Spacebar and Enter)
✅ Voice Access
✅ Narrator in scan mode
For all of these (except Voice Access), I've confirmed that holding the
Alt button while invoking the JSON button opens defaults.json.
Closes#18770Closes#12003
(cherry picked from commit a8a47b93671361e529ff9f967d0e7c1b028eebb9)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZrZKs PVTI_lADOAF3p4s4AxadtzgZrDtw
Service-Version: 1.23
This pull request adds support for resetting the various color table
entries and xterm resource values back to their defaults.
Building on the default color table James introduced in #17879, it was
relatively straightforward to add support for resetting specific
entries.
This implementation cleaves tightly to observed behavior in xterm(379)
rather than observed behavior in libvte(0.70.6). They differ in the
following ways:
- xterm rejects any OSC [110..119] with any number of parameters; libvte
accepts it but only resets the first color.
- When passed a list of color indices to reset in 104, xterm resets any
colors up until the first one which fails to parse as an integer and
does _not_ reset the rest; libvte resets all parseable color indices.
I was unable to verify how these reset commands interact with colors set
via `DECAC Assign Color` so I went with the implementation that made the
most sense:
- Resetting the background color with `110` also restores the background
color alias entry to its pre-`DECAC` value; this results in the
perceived background color returning to e.g. index 0 in conhost and the
`background` color in Terminal.
- _ibid._ for the foreground color
Refs #18695
Refs #17879Closes#3719
(cherry picked from commit 5f311506dcaa93c24214819e02fa027151c47fe1)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZOWsQ
Service-Version: 1.23
This PR adds a new policy definition to the ADMX templates for settings
the default Terminal application in Windows.
> [!Note]
> This PR does not change any code of Windows, Console Host or Windows
Terminal. It only adds the definition for a new policy to the templates.
I got the registry values form the documentation and by testing the
values.
The policy is only available as user policy because the registry values
have to be in HKCU.
The Policy is implemented as preference (not inside the Policy key) and
therefore keeps it's value on removing (not configured) it. You can see
this in `gpedit.msc` on the policy symbol and the hint in the
description.
Closes#18302
Refs #18303
(cherry picked from commit 68d9e0d0389101d65f91e5f3bd3fda34df7564f3)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZlw40
Service-Version: 1.23
Use DECSC/DECRC and XTPUSHSGR/XTPOPSGR while redrawing
popups, since they're drawn using the current popup colors.
I wish we could just use the reverse video rendition...
Closes#18742
## Validation Steps Performed
* Run `color 3f` and then press F7
* Works fine in conhost (VtPipeTerm) ✅
* Works as expected (black background) in VS Code ✅
(cherry picked from commit 8b01f546cb5c1d5895d0fa517fd6bbedc9991a1b)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZd3bs
Service-Version: 1.23
Add additional information to 2 error scenarios when launching a
different profile in the `ConptyConnection.cpp` file.
- Requires Elevation
- File Not Found
Created a profile that required elevation and verified the error
message. Created profile that passed a made up command and verified the
error message.
Closes#7186
(cherry picked from commit f7e853cd9f515ff0c7e52ab0eb0604bb95d47ba3)
Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZlxJY
Service-Version: 1.23
