This adds a `safeUriSchemes` global setting which lets you define
hyperlink URI schemes which the user considers safe. No confirmation
dialog will be shown when trying to open hyperlinks which use these
schemes.
- This solves the root issue, but doesn't introduce any UI or
documentation changes. I wanted to validate the approach and
implementation with you first.
- I closely followed the code handling the `disabledProfileSources`
setting, which is of the same type.
- This feature does not change the behavior of `http`, `https` and
`file` schemes.
Validation
I ran the dev terminal, and tested the behavior by clicking on `vscode`
hyperlinks generated by ripgrep with various `safeUriSchemes` settings:
- Setting not defined - asks for confirmation
- `["vscode"]` - does not ask for confirmation
- `["foo", "vscode"]` - does not ask for confirmation
- `["foo"]` - asks for confirmation
- `null` - asks for confirmation
- `[]` - asks for confirmation
- `[""]` - asks for confirmation
- `[{"foo": "bar"}]` - fails to deserialize (as expected)
A few uinit tests failed, but they seem unrelated to these changes:
- `KeyBindingTests` in `UnitTests_SettingsModel`, probably because I use
an AZERTY keyboard.
- A few `Conhost` tests, but I didn't touch this part
Refs #20065Closes#20191
(cherry picked from commit fb71a0462e)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgshlaM
Service-Version: 1.24
This commit implements two fixes for the integer overflow/out-of-bounds
write reported in #20149.
First, it catches any exception generated in sixel char processing
(which will prevent `out_of_memory` or `bad_alloc` from being ignored
sight-unseen, and will prevent the consumption of further DCS content).
Second, it prevents us from allocating memory for an image which will
never be displayed (because it exceeds the height of the display.)
This supersedes prior work in #20153 for the same issues.
Closes#20149Closes#20153
Co-authored-by: James Holderness <j4_james@hotmail.com>
(cherry picked from commit c829d4ca54)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgrY_zM
Service-Version: 1.24
This commit ensures that we only set the starting title once when we
open a new terminal pane.
It also consolidates all title selection into Terminal::GetConsoleTitle,
which is now used in the TitleChanged event.
TitleChanged no longer stores a separate copy of the starting title if
an application attempts to _clear_ the title; that seems like a poorer
implementation of what we already had.
This supersedes work in #20204.
Closes#19340Closes#20204
Co-authored-by: imsh <im.shaedar@gmail.com>
(cherry picked from commit b991eb048e)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgfZJdA
Service-Version: 1.24
This fix addresses issue #19983 where resizePane actions unconditionally
consume keystrokes even when no resize can occur.
The fix follows the same pattern used for moveFocus and swapPane fixes:
- Changed Tab::ResizePane to return bool indicating success
- Changed TerminalPage::_ResizePane to return bool from ResizePane
- Updated _HandleResizePane to set args.Handled() based on whether
resize succeeded
This allows the keychord to propagate to the terminal when no resize can
occur, matching the behavior of moveFocus and swapPane (#6129).
Closes#19983
---------
Co-authored-by: nmurrell07 <nmurrell07@users.noreply.github.com>
Co-authored-by: Dustin L. Howett <dustin@howett.net>
(cherry picked from commit dadde2fb11)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgr4epk
Service-Version: 1.24
It is possible to craft a packet whose `len` is `0x80000001`.
We should not produce values that do not fit in size_t (on e.g. x86).
Reject them summarily.
(cherry picked from commit 8edac5fb12)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgr4enM
Service-Version: 1.24
An internal AI correctly flagged that we aren't calling
`UnadviseSink()` in case a later `Initialize()` call fails.
We can easily fix this by calling `Uninitialize()`.
(cherry picked from commit 36fb444d3e)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgnOwC0
Service-Version: 1.24
This should prevent an outage like the one from #19764
(cherry picked from commit 84e807cbeb)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgrZtm8
Service-Version: 1.24
## Summary of the Pull Request
Dustin reported this bug to me. Thankfully it was an easy fix.
## References and Relevant Issues
Bug from implementing #5099
## Validation Steps Performed
Double-click ____ of right-most cell of a word selects the current word
✅ right-half
✅ left-half
(cherry picked from commit 115ec2cbb9)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgraAYs
Service-Version: 1.24
This commit fixes a regression in v1.24, where composing Korean text
in-between existing characters causes text to the right to be hidden.
This is problematic for the Korean IME, because it commonly inserts
the composed syllable between existing characters.
The fix compresses (removes/absorbs) available whitespace to the right
of the composition to make space for any existing text. This means
that a composition now virtually acts in insert mode.
Closes#20040
Refs #19738
Refs #20039
1. Korean IME: compose `ㄷ` between `가` and `나` → display shows `가ㄷ나`,
`나` visible.
2. TUI box (vim prompt with padding): compose inside padded text box →
border preserved in place.
3. Composition at end of line (no chars to right): unaffected.
4. English and other IME input: not affected (no active composition
row).
Co-authored-by: jason <drvoss@users.noreply.github.com>
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
(cherry picked from commit 7a83c0f167)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgo0Jpc
Service-Version: 1.24
We are getting a sufficient number of LLM-generated security reports
telling us that Ctrl+click and a tooltip are insufficient protection
from users clicking on links to dangerous things.
This commit displays a warning that prevents users from blindly clicking
on dangerous things.
Dangerous things include:
- any non-http and non-https and non-file URLs
- any file URLs that point to something understandable as a "program"
(so, something which resides in `PATHEXT`.)
In doing this, I learned that `til::ends_with_insensitive_ascii` was
broken.
I also learned that ContentDialogs summoned by any event handler out of
TermControl::Pointer* would lose focus immediately. It turns out that in
the absolute earliest days of Terminal, when we first created the
UserControl that became TermControl, we added our Tapped event handler.
It unconditionally focused the control.
Since `Tapped` is a higher-level event handler than `PointerPressed`, it
was firing after the gesture that opened the content dialog and stealing
focus back.
I'm fairly certain we don't need it.
Refs #7562
(cherry picked from commit 81170aff78)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgpOYmk
Service-Version: 1.24
### Summary
Updates terminal to gain foreground focus when a user drags and drops a
file into the terminal.
### Changes
Updates the `DragDropHandler` to call `SetForegroundWindow`.
### Validation
* Built and deployed locally
* Manually verified terminal gains focus when dragging and dropping
Closes#19934
(cherry picked from commit a1a43a4ff5)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgpBNEE
Service-Version: 1.24
Selection in VT mouse mode has been feeling a little weird. I've made a
few changes in this space to improve the overall experience when in vt
mouse mode:
- don't round selection positions: this means that you now highlight the
cell you're on if you're going right, and the adjacent cell if you're
going left
- fix drag-left excluding the current cell
- #9608: shift+click now clears any existing selection instead of
extending it. This feels more intuitive since Shift already works as the
override modifier
Somewhat related to #18106
## Validation
✅ alt selections feel consistent
✅ selecting in VTMM feels accurate (selects the cell we started on)
✅ creating new selections (aka clearing old selection) in VTMM feels
intuitive (forwards and backwards)
Closes#9608
(cherry picked from commit 2e33056fd8)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgna3WE
Service-Version: 1.24
## Summary of the Pull Request
This includes the memory leak fixes that @lhecker and I investigated as
a part of #19710.
The `ITextRangeProvider`s (namely `UiaTextRange`s) weren't being
destroyed after they were done being used by the screen reader.
## Validation Steps Performed
In my own testing, I set a breakpoint on the destructor for
`UiaTextRangeBase`. Prior to this change, that destructor would mainly
be called when the terminal control was closed, which would result in us
leaking these objects. With this change, I've confirmed that these text
ranges are being destroyed immediately after they are done being used
(without needing to close the terminal control).
## PR Checklist
Closes#19710
(cherry picked from commit e2110e716c)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgnCP0M
Service-Version: 1.24
## Summary of the Pull Request
I was becoming frustrated with getting in a state where a CLI app (i.e.
Copilot CLI) enters some VT state (like mouse mode) then doesn't unset
it when it accidentally exits. I normally use "Restart connection" to
keep the buffer and connect again. Problem is, "restart connection"
didn't actually reset the internal state! So I would type and get a
bunch of lingering VT escape sequences. This bug is tracked over in
#18425 in a more generic way.
This fixes that bug by doing the following:
- update `ITermDispatch::HardReset()` -->`HardReset(bool erase)`
- `erase=true` does what `HardReset()` already did
- `erase=false` skips over clearing the screen and resetting the cursor
position
- expose `HardReset(false)` as `HardResetWithoutErase()` by piping it up
through `Terminal` --> `ControlCore` --> `TermControl`
- update the restart connection handler
- `TerminalPage::_restartPaneConnection()` now calls
`HardResetWithoutErase()` before setting the new connection
- this is also the same route for the "Enter to restart connection"
scenario (text displayed when connection ends)
Relevant notes from PR discussion:
- `PSEUDOCONSOLE_INHERIT_CURSOR` is passed into the new connection via
`_restartPaneConnection()` --> `_duplicateConnectionForRestart()` -->
`_CreateConnectionFromSettings(profile,
*controlSettings.DefaultSettings(), true)`
## Validation Steps Performed
- Used this to enter mouse tracking mode: `Write-Host -NoNewline
"`e[?1003h`e[?1006h"`
- mouse selection doesn't work as usual (expected)
- invoke "restart connection" action
- mouse selection works as usual
Closes#18425
(cherry picked from commit ec939aabda)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgpBL5w
Service-Version: 1.24
## Summary of the Pull Request
Updates the scroll handler to check the selection mode before updating
the markers.
Introduced in #19974
## Validation Steps Performed
`ls` --> create selection --> scroll away and back
✅ keyboard selection: markers are present both times
✅ mouse selection: markers are missing both times
(cherry picked from commit 3104c8feb2)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgo0ICA
Service-Version: 1.24
Fix a regression introduced in v1.24 where pressing an arrow key during
Korean IME composition caused the committed character to be inserted at
the wrong cursor position.
Before #19738, the Korean IME activated through IMM32 (excluded from TSF
by `TF_TMAE_UIELEMENTENABLEDONLY`) and was not affected by
`TermControl::_KeyHandler` forwarding keys to the PTY during
composition. After #19738, the Korean IME activates through TSF, making
a missing composition guard in `_KeyHandler` visible as a bug.
The sequence of events that causes the bug:
1. User presses Left arrow during active Korean IME composition (e.g.
composing `가`).
2. `_KeyHandler` calls `_TrySendKeyEvent(VK_LEFT)` which enqueues
`\x1b[D` to the PTY input queue. The cursor moves.
3. TSF processes the key. The Korean IME sees the arrow and ends the
composition.
4. `OnEndComposition` schedules `_doCompositionUpdate` with
`TF_ES_ASYNC`.
5. The async session fires, reads finalized text `가`, calls
`HandleOutput("가")`.
6. PTY processes `[\x1b[D, "가"]`: cursor moves left first, then `가` is
inserted at the wrong (already-moved) position.
The fix adds a guard before `_TrySendKeyEvent`, which mirrors the
existing behavior in conhost (windowio.cpp). When TSF has an active
composition, key events are not converted into input. The Korean IME
re-injects navigation and confirmation keys after the composition ends,
at which point `HasActiveComposition()` returns false and they are
forwarded normally.
**Historical note:** This guard was not needed before PR #17067 (v1.22)
because the old implementation used WinRT `CoreTextServices` via XAML
(`TSFInputControl.xaml`). The XAML framework intercepted composition key
events before `_KeyHandler`. The new custom Win32 TSF context in #17067
no longer does this. The bug was latent from v1.22 but only became
visible for Korean in v1.24 when #19738 removed
`TF_TMAE_UIELEMENTENABLEDONLY`.
## Validation Steps Performed
1. Open Windows Terminal with Korean IME (Dubeolsik layout).
2. Type `rk` to begin composing `가` (composition active, syllable not
yet committed).
3. Press the Left arrow key.
4. Before fix: `가` is inserted one cell to the left of the intended
position.
5. After fix: `가` is inserted at the correct position, then cursor moves
left.
Also verified:
- Normal Korean text input (typing without arrow keys) still works
correctly.
- Arrow key navigation when no composition is active still works
correctly.
- English and other IME input is not affected.
Closes#20038
Refs #19738
(cherry picked from commit 14f4271954)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgo0JpQ
Service-Version: 1.24
Some applications have come to rely on an "empty" bracketed paste packet
to indicate that the clipboard was _requested,_ but not sent. Some
agentic CLI tools use this to guess whether the clipboard contained e.g.
an image or otherwise unserializable data.
Apparently, gnome-terminal and VS Code do this; others as well (I tested
xterm, konsole, gnome-terminal and I can't remember which ones did and
which ones did not.)
Refs #19517
(cherry picked from commit 2870a702f4)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgotgA8
Service-Version: 1.24
This commit fixes the following error that occurs when attempting to use the
`Microsoft.Windows.Console.ConPTY` nupkg in a Visual C++ project:
MSB4019: The imported project "C:\Microsoft.Windows.Console.ConPTY.props" was not found.
Based on the list of reserved and well-known properties, the property
`MSBuildThisProjectDirectory` does not appear to exist. This PR
replaces it with the correct property, `MSBuildThisFileDirectory`.
(cherry picked from commit be5dcf8e7a)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgotQIo
Service-Version: 1.24
## Summary of the Pull Request
Fix `copyOnSelect` right-click paste overwriting the clipboard with a
stale selection instead of pasting the current clipboard contents.
## Detailed Description of the Pull Request / Additional comments
When `copyOnSelect` is enabled, the selected text is already copied to
the clipboard on left mouse button release in `PointerReleased`. The
selection is intentionally left visible as a visual reference (the
`_selectionNeedsToBeCopied` flag is set to `false` to track that the
copy already happened).
However, the right-click handler in `PointerPressed` unconditionally
called `CopySelectionToClipboard()` before pasting, ignoring both the
`copyOnSelect` setting and the `_selectionNeedsToBeCopied` flag. This
caused any still-visible selection to be re-copied to the clipboard,
overwriting whatever the user may have copied from another application
(or another terminal tab) in the meantime.
This change splits the right-click behavior based on the `copyOnSelect`
setting:
- **`copyOnSelect: true`** — Skip the redundant copy, clear the
selection, and paste directly. The text was already copied on mouse-up.
- **`copyOnSelect: false`** — Preserve existing behavior: copy the
selection (if any), clear it, and paste only if there was no selection
to copy.
## Validation Steps Performed
1. Set `"copyOnSelect": true` in `settings.json`.
2. Selected text in a terminal pane - verified it was copied to
clipboard on mouse-up.
3. Switched to Notepad, copied different text ("NEW TEXT").
4. Switched back to Terminal (selection still visible), right-clicked —
verified "NEW TEXT" was pasted, not the old selection.
5. Verified right-click with no active selection still pastes clipboard
contents.
6. Verified right-click immediately after selecting (no app switch)
pastes the just-selected text.
7. Set `"copyOnSelect": false` — verified right-click still copies
selection first, then pastes only when no selection exists (original
behavior unchanged).
8. Verified tab-switching with an active selection does not cause stale
clipboard overwrites on right-click.
## PR Checklist
Closes#14465 (dupe of #19942)
---------
Co-authored-by: Sagar Bhure <sagarbhure@microsoft.com>
(cherry picked from commit ad7b34e55f)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgn30Lw
Service-Version: 1.24
Closes#19922
## Validation Steps Performed
* The repro now works as expected ✅
(`CreatePseudoConsole({1,20})` + `WriteFile("キ")`)
(cherry picked from commit ddf514e99e)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgn2sRY
Service-Version: 1.24
## Summary of the Pull Request
Pretty straightforward
## Validation Steps Performed
✅ Selection markers are present after scrolling them out of view and
scrolling back
Closes#17135
(cherry picked from commit 14ee19fc27)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgna-WQ
Service-Version: 1.24
It's creating a lot of noise for folks, and it is not particularly
_helpful_ since it does not specify a location or even name which
resource failed to load or parse.
On stable, let's just silently ignore them.
Refs #19964
(cherry picked from commit 6d7fac999a)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgnTk_w
Service-Version: 1.24
## Summary
- Fix inability to copy terminal text via Ctrl+C when the search dialog
is open
- Root cause: click-and-drag doesn't call `Focus()` because `_focused`
is already `true` (set by the search box's bubbling GotFocus)
- Fix: also focus the terminal when the search box contains keyboard
focus
## Detailed Description of the Pull Request / Additional comments
When the search dialog is open and the user click-drags in the terminal
to select text, `_PointerPressedHandler` skips
`Focus(FocusState::Pointer)` because `_focused` is `true`. The
`_focused` flag is `true` because the `SearchBoxControl` is a child of
`TermControl` in the XAML visual tree, so `TermControl`'s
`_GotFocusHandler` fires (via bubbling `GotFocus`) when the search box's
`TextBox` gains focus, setting `_focused = true`.
The fix adds a `ContainsFocus()` check so that focus is explicitly moved
to the terminal when the search box has keyboard focus. This makes
click-drag behavior consistent with tap behavior (`_TappedHandler`
already focuses unconditionally) and uses the same `ContainsFocus()`
pattern already established at lines 1569 and 2366 in the same file.
## Validation Steps Performed
- Verified click-drag + Ctrl+C copies selected text when search dialog
is open
- Verified simple click (tap) in terminal while search is open still
works
- Verified clicking in the search box retains focus in the search box
- Verified typing in search box still works when it has focus
- Verified Escape still closes the search box
- Verified Ctrl+C with no selection while search is open doesn't break
- Code formatted with clang-format
## PR Checklist
Closes#19908
(cherry picked from commit e2d51636cd)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgnN_t0
Service-Version: 1.24
Apparently, on some (internal) variants of Windows `TF_CategoryMgr`
can exist while `TF_DisplayAttributeMgr` is absent. This is likely
a variant configuration error, but we shouldn't crash anyway.
Closes MSFT-61309810
(cherry picked from commit 30b1456ffe)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgnOd-c
Service-Version: 1.24
Our last build failed because it tried to pass "10621.0" off as a
uint64. I didn't know it had to be a single number... so let's use the
3-component equivalent (which would have been 1.24.260303001)
(cherry picked from commit 5828fb5ce5)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgms2-I
Service-Version: 1.24
A few features were marked "always disabled" and then enabled in dev,
canary and preview. I simplified those to "always enabled" and disabled
in release instead. This required changes to Generate-FeatureStaging to
make it consider `WindowsInbox` a Release branding (which, honestly, it
always should have been.)
- Feature_DynamicSSHProfiles
- Feature_ShellCompletions
- Feature_SaveSnippet
- Feature_QuickFix
Feature_DisableWebSourceIcons was deprecated in #19143, but the XML file
never got the memo.
(cherry picked from commit afb4752102)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgmV4c4
Service-Version: 1.24
Two main changes:
- the build was failing for ARM64 because the build agents run out of
memory downloading artifacts; this is a known issue that nobody cares to
fix (and it pertains to using the x64 emulated agent host on native
arm64 machines)
- deleting the PDBs shrinks the build output by 2500MB :P
- we had to switch to a new type of identity for publishing nuget
packages to our cross-org feed
I've verified that we get counts _and_ can even produce final PGO count
packages for both architectures!
(cherry picked from commit 8f3d1d8d01)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgmV1Qg
Service-Version: 1.24
## Summary
Fixes tab row losing acrylic material when window is unfocused, even
when "Allow acrylic material in unfocused windows" is enabled.
## References
Fixes#19544
## Changes
Modified `_updateThemeColors()` in `TerminalPage.cpp` to check both
window focus state and `EnableUnfocusedAcrylic` setting.
## Testing
- Verified acrylic persists when window loses focus (with setting
enabled)
- Verified acrylic removed when setting disabled (expected behavior)
---------
Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com>
(cherry picked from commit 28c98c5dc1)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgjj55A
Service-Version: 1.24
Only respond to any search changes in the command palette if the command
palette is visible. Without this check, a previewable action's preview
can appear after the command palette is closed.
## Validation Steps Performed
Preview no longer appears after the command palette is closed
## PR Checklist
Closes#18737
(cherry picked from commit 127775118d)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgmFfaU
Service-Version: 1.24
I just submitted a vpack to Windows and it turned out to be version
"0.0.5". Whoops.
(cherry picked from commit 3ec372c176)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgkbCsw
Service-Version: 1.24
When text scrolls in and out of view, depending on the length
of the scrollback and latency of input, `GetSearchHighlightFocused`
would change which would trigger a `ScrollToSearchHighlight` call.
This PR changes the behavior such that only actively changing the
search mask triggers a search (typing text or pressing enter).
Closes#19754
## Validation Steps Performed
* Brining text in and out of view doesn't scroll ✅
* Toggling the aA button scrolls results into view ✅
(cherry picked from commit 71409f84f7)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgkLCdk
Service-Version: 1.24
## Summary of the Pull Request
Updates the NullableColorPicker to use a flyout instead of a content
dialog. Frankly, it should've been this way from the start.
#19561 is an issue regarding the rectangle on the right side of the
picker. The complaint being that it should be something more useful than
a preview, an idea being that it could be a lightness gradient.
Unfortunately, the WinUI color picker doesn't let you do that. It's just
a plain preview.
That said, there's a lot of customizations that can be added still to
increase value here. To name a few:
- IsColorSliderVisible --> a color slider to adjust the lightness of the
color (as desired in #19561)
- IsHexInputVisible --> an input field to see and adjust the hex value
directly
- IsColorChannelTextInputVisible --> several input fields to adjust
individual RGB channels or switch over to HSV
However, the content dialog doesn't allow for text input due to a WinUI
bug and it's too small to display all of those controls.
Instead, I just discarded the content dialog altogether and opted into a
flyout. This makes it a more consistent experience with the other color
pickers (i.e. tab color, edit color scheme page). This also adds space
for all of the functionality mentioned above (those properties are
enabled by default).
## Validation Steps Performed
✅ selecting a color still works
Closes#19561
(cherry picked from commit 38d2fdad5f)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgkgbZA
Service-Version: 1.24
This PR closes#12632 by dimming the caption controls in the titlebar
when unfocused. Leaves them intact when in high contrast mode. The color
used is borrowed from PowerToys' unfocused color.
## Validation Steps Performed
Tested by hovering and unhovering in focused and unfocused states, as
well as in high contrast mode. States are consistent and applied
correctly. I did notice that clicking on the titlebar wouldn't put it
into focus unless I also moved my mouse though, but that is also present
in the release branch.
Closes#12632
(cherry picked from commit 8d94edd7b0)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgkC_KM
Service-Version: 1.24
We used to run the cloud shell connector in an intermediate process
because our VT implementation lived mostly in conhost. James fixed that
up over the intervening years, and since #17510 landed Terminal is
exposed to 100% of application-originated VT. That means we no longer
need this workaround, its build steps, or anything else about it.
Closes#4661
(cherry picked from commit 4b946c0d5c)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgkCt5k
Service-Version: 1.24
We're seeing some crashes where we call `GetFocusedElement(null)`.
MSFT-54686865
MSFT-53824167
Possibly also #19751
(cherry picked from commit 0ee3cfb3fd)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgjzNUE
Service-Version: 1.24
After the coroutines resume, `this` may have already been destroyed.
So, this PR adds proper use of `get_weak/strong`.
Closes#19745
(cherry picked from commit a528141fe6)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgjzPAI
Service-Version: 1.24
## Summary of the Pull Request
When `useAcrylicInTabRow` is enabled, the theme's `tabRow.background`
color is now used as the acrylic tint instead of being ignored.
## References and Relevant Issues
Fixes#19604
## Detailed Description of the Pull Request / Additional comments
Previously, the code had mutually exclusive branches for handling
`useAcrylicInTabRow` and theme `tabRow.background`. When acrylic was
enabled, the theme color was never evaluated.
This PR extracts the theme's tabRow color first, then uses it as the
acrylic tint if set, falling back to the default if no theme color is
specified.
## Validation Steps Performed
Tested with `useAcrylicInTabRow: true` and custom `tabRow.background` -
acrylic now shows the theme color as tint
## PR Checklist
Closes#19604
(cherry picked from commit 691568195b)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgjj6I8
Service-Version: 1.24
WinUI doesn't react well to lots of text,
so this PR caps the max. amount shown.
Related to #9232
(cherry picked from commit d05dd85275)
Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgjXLaM
Service-Version: 1.24
