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
## Validation Steps Performed
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_lADOAF3p4s4BQX0-zgo0JpY
Service-Version: 1.25
Failure to do so will result in every console API requiring a cursor
update stalling for 500ms because we sent the update to the wrong
buffer.
Closes#20092
(cherry picked from commit 031998bfc3)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgpcJzw
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgpOYmc
Service-Version: 1.25
### 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_lADOAF3p4s4BQX0-zgpBND8
Service-Version: 1.25
## Summary of the Pull Request
This PR updates `VsDevShellGenerator` to use the `vs-pwsh` icon in
generated profiles, if modern PowerShell has been detected.
## References and Relevant Issues
The icons were added in #17706, but are not used anywhere.
## Detailed Description of the Pull Request / Additional comments
* Updated `VsDevShellGenerator::GetProfileCommandLine` to accept a
`bool& isPwsh` parameter, which is set to whether the generated profile
command line is using modern PowerShell. This value gets passed to
`VsDevShellGenerator::GetProfileIconPath`'s new parameter, which
determines whether to return the icon for `powershell` or `pwsh`.
(cherry picked from commit e0400150d0)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgpBNIk
Service-Version: 1.25
This restores the behavior of ReadFile to that of Windows 7.
Closes#4958
(cherry picked from commit 80e4b3c947)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgpBM28
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgna3V8
Service-Version: 1.25
## 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_lADOAF3p4s4BQX0-zgpBL5s
Service-Version: 1.25
This adds support for OSC 7 which is the same as OSC 9;9 but using
file URIs. As per the previous discussion in #8214, the problem is
that WSL shells emit URIs that can't work because the hostname in
the URI translates to an UNC path with an non-existing hostname.
In my opinion this doesn't deter the fact though that OSC 7 works
just fine for a native Windows application.
In the future we should consider trying to detect WSL file URIs
and translating it to the `--cd` argument for `wsl.exe`.
All of the heavy lifting for parsing the URI is done by
`PathCreateFromUrlW`. It just had to be plugged into the OSC 9;9 code.
Closes#3158
## Validation Steps Performed
* Launch fish-shell in WSL
* Duplicate tab works ✅
* (And because it doesn't work without using
`IsValidDirectory` I know that OSC 7 works ✅)
(cherry picked from commit 4ce79d7289)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgpBLe8
Service-Version: 1.25
This PR is 90% wiring up OOP interfaces.
Closes#19926
## Validation Steps Performed
* Run `github.com/xtermjs/vtc`
* Observed `UnknownSequence` calls under a debugger
(cherry picked from commit da0446a7d1)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgpBLzY
Service-Version: 1.25
## 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_lADOAF3p4s4BQX0-zgo0IB8
Service-Version: 1.25
## Summary of the Pull Request
Popups are in their own separate tree, so we had to find it and set the
theme ourselves.
## Validation Steps Performed
Prereq: Windows theme = light + terminal theme = dark
✅ settings search dropdown is dark theme
Closes#19927
(cherry picked from commit c562dad15d)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgnsPtk
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgo0JpM
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgotgA4
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgotQIk
Service-Version: 1.25
## 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_lADOAF3p4s4BQX0-zgn30Ls
Service-Version: 1.25
Closes#19922
## Validation Steps Performed
* The repro now works as expected ✅
(`CreatePseudoConsole({1,20})` + `WriteFile("キ")`)
(cherry picked from commit ddf514e99e)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgn2sRU
Service-Version: 1.25
## 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_lADOAF3p4s4BQX0-zgna-WM
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgnTk_s
Service-Version: 1.25
## 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_lADOAF3p4s4BQX0-zgnOgZ8
Service-Version: 1.25
## 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_lADOAF3p4s4BQX0-zgnOhC8
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgnOg_4
Service-Version: 1.25
Use GetAttribute('x:Name') instead of .Name in GenerateSettingsIndex.ps1
to avoid PowerShell's XML integration returning the element tag name
(e.g. 'local:SettingContainer') when x:Name is absent.
Also add missing x:Name attributes to:
- Compatibility.xaml: AmbiguousWidth SettingContainer
- NewTabMenu.xaml: AddRemainingProfiles and CurrentFolderIcon containers
## Summary of the Pull Request
Fix GenerateSettingsIndex.ps1 emitting "local:SettingContainer" as the
element name in the generated index when a SettingContainer has no
x:Name attribute.
## References and Relevant Issues
Per DHowett's comment - the root cause is PowerShell's XML integration:
$element.Name returns the XML element tag name (e.g.
local:SettingContainer) when no x:Name attribute exists.
## Detailed Description of the Pull Request / Additional comments
Two changes:
- GenerateSettingsIndex.ps1: Replace $settingContainer.Name with
$settingContainer.GetAttribute("x:Name"), which correctly returns an
empty string when the attribute is absent instead of the element tag
name.
- Add missing x:Name attributes to three SettingContainer elements:
- Compatibility.xaml: AmbiguousWidth (Globals_AmbiguousWidth)
- NewTabMenu.xaml: AddRemainingProfiles
(NewTabMenu_AddRemainingProfiles)
- NewTabMenu.xaml: CurrentFolderIcon (NewTabMenu_CurrentFolderIcon)
- This fixes four incorrect IndexEntry lines in the generated output
that previously contained L"local:SettingContainer" as the element name.
## Validation Steps Performed
Ran GenerateSettingsIndex.ps1 before and after - confirmed the four
incorrect entries with L"local:SettingContainer" are now generated with
the correct x:Name values (or empty string where appropriate).
## PR Checklist
Closes#19929
Co-authored-by: Sagar Bhure <sagarbhure@microsoft.com>
(cherry picked from commit 8cad67020f)
Service-Card-Id: PVTI_lADOAF3p4s4BQX0-zgnOg9Q
Service-Version: 1.25
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_lADOAF3p4s4BQX0-zgms2-E
Service-Version: 1.25
When a new command is added or an existing command's name is changed,
make sure we update the top-level command list so that it appears there
when the user navigates back to the actions page
## Detailed Description of the Pull Request / Additional comments
Added a new `_CommandListDirty` flag to the `ActionsViewModel`. When a
new command is added or a command's name is changed the flag is set.
When navigating to the top-level actions page, we regenerate the
`_CommandList` if the flag is set.
## Validation Steps Performed
Adding a new command or updating a command's name is now reflected
correctly when navigating back to the actions page.
This only gates VT-driven clipboard writes (OSC 52), not
user-initiated copy.
Closes#19051
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
Co-authored-by: Dustin L. Howett <dustin@howett.net>
This PR introduces `compatibility.ambiguousWidth` as a **global**
compatibility setting (`narrow` default, `wide` optional).
The default remains `narrow`.
Why global-only in this PR:
- Width detection is currently process-wide (`CodepointWidthDetector`
singleton).
- True profile-level ambiguous-width behavior would require broader
architectural changes and is intentionally deferred to a follow-up
design/PR.
What this PR guarantees:
- Terminal-side handling is consistent end-to-end for the selected
ambiguous-width policy (rendering path + ConPTY/host propagation).
Known limitation:
- Some client applications (for example PSReadLine/readline-based apps)
may still compute character widths independently.
- In such cases, cursor movement or Backspace behavior can differ from
visual cell width even when terminal-side policy is consistent.
This is a compatibility/readability trade-off feature:
- `narrow`: prioritize cross-application compatibility.
- `wide`: prioritize readability with many CJK fonts.
Closes#153Closes#370
Refs #2928
Refs #2049, #2066, #2375, #900, #5910, #5914
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
## Summary of the Pull Request
Fixes a bug where a partially visible URL would not be detected. This is
fixed by expanding the search space by 1 viewport height in both
directions.
The `_patternIntervalTree` now operates in the absolute-buffer space as
opposed to the viewport-relative space. It's a bit of an annoying
change, but the alternative would be to keep track of the offset used by
the method above, which I find more annoying, personally. As a part of
this change, I made it a bit more clear when something is
viewport-relative vs buffer-absolute.
Regarding mark mode hyperlink navigation, now that everything is in the
absolute-buffer space, I'm able to fix some of the issues in #13854. I
removed `_selectionIsTargetingUrl` and fixed/validated navigating to
hyperlinks that are partially visible.
## Validation Steps Performed
Detects URL that is...
✅ fully visible
✅ partially cropped off the top
✅ partially cropped off the bottom
✅ Above scenarios work with mark mode hyperlink navigation
✅Tests added
Closes#18177Closes#13854
## 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>
This pull request resolves a longstanding issue (which probably nobody
but me cared about :P) where gridlines and underlines did not change
color to match the selection or search highlight foreground.
During brush preparation, we stash the underline color; during line
rendering we store it in a third bitmap and during rendering in each
backend we read the colors out of the appropriate bitmap.
The gridlines come from the foreground bitmap and the underlines from
the new underline bitmap.
I've updated each instance of append*Line to break the line-to-render up
by color span.
We are, therefore, no longer passing the stroke color in each gridline
payload.
The original console renderer supports painting the gridlines in
different colors for each half of a 2-cell glyph. That functionality no
longer works in Atlas. To fix it, we would need to move underline _span_
preparation into PaintBufferLine (so that we could apply the right
colors to the bitmap mid-cell.)
Known Issues
------------
- D2D only; dotted lines which are broken by a highlight have doubled
dots (because we draw them as individual line segments and without a
global geometry like curly lines.)
- Atlas (all); grid line colors can no longer change in the middle of
a 2-cell glyph.
Tested By
---------
RenderingTests
## Summary of the Pull Request
Cleans up GenerateSettingsIndex.ps1 by addressing the feedback Dustin
left in #19519
## Validation Steps Performed
✅ SUI search works
## Summary of the Pull Request
There is an issue where clicking an item (with the mouse) from the auto
suggest box's dropdown would fail on the first try, but the dropdown
gets reopened automatically and clicking an item after that works. This
is because `AutoSuggestBox` has `UpdateTextOnSelect` defaulted to
`True`, but we also have a `SuggestionChosen` handler that effectively
does the same thing, and the two were conflicting. This commit fixes
that by removing our `SuggestionChosen` handler.
## Verification steps performed
Selecting an item from the dropdown with mouse works on first try.
Keyboard flow continues to work as expected.
## Summary of the Pull Request
Consolidates the navigation functions in `MainPage` for the settings UI.
This involved:
- combining all separate `_Navigate()` functions into one big one
- deduplicating `SettingsNav().SelectedItem()` calls
- removing the unnecessary variable for a crumb (just inline creation
and registration)
- removing the `elementToFocus` staging behavior for color schemes and
profile sub pages
## References and Relevant Issues
Builds off the work done in #19519 and #19831
## Validation Steps Performed
Navigate to...
✅ simple top-level pages: Startup, Interaction, Appearance, Rendering,
Compatibility, Add profile
✅ Color schemes and subpages
✅ Actions, subpages
✅ New Tab Menu and folder subpages
✅ Extensions, subpages, and profile/scheme navigation
✅ defaults profile and subpages
✅ specific profile and subpages
Also tested discarding changes on these pages.
✅ search still works and navigates to the correct element
## PR Checklist
Closes#19866
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
## Summary of the Pull Request
Adds search functionality to the settings UI. This is added to an
`AutoSuggestBox` in the main `NavigationView`. Invoking a result
navigates to the proper location in the settings UI and focuses the
setting, when possible.
## References and Relevant Issues
Based on https://github.com/microsoft/PowerToys/pull/41285
## Detailed Description of the Pull Request / Additional comments
- tools/GenerateSettingsIndex.ps1: parses all the XAML files in the
settings UI for SettingsContainers and builds a search index from them
- XAML changes: ensures all SettingContainer objects have an `x:Name` so
that we can navigate to them and bring them into view.
- TerminalSettingsEditor/Utils.h: implements `BringIntoViewWhenLoaded()`
which navigates to the relevant part of the UI. This is called in
`OnNavigatedTo()` for each page.
- fzf was moved out of TerminalApp so that TerminalSettingsEditor can
access it
- There's a few main components to searching, all of it is in
`MainPage`:
- `MainPage::_UpdateSearchIndex()`|`SearchIndex::Reset()`: loads the
search index generated by `GenerateSettingsIndex.ps1`; provides
additional localization, if needed
- `MainPage::SettingsSearchBox_TextChanged`:
- detect that text changed in the search box
- perform the actual search in `SearchIndex::SearchAsync()`. This is a
HEFTY async function that can be cancelled. It needs a lot of context
passed in to expand the search index appropriately (i.e. build awareness
of "PowerShell" profile and generate results appropriately). This is
also where fzf is used to perform weighted matching.
- the weighted matching itself is pretty complicated, but all the
associated bonus weights are at the top of SearchIndex.cpp.
- `SettingsSearchBox_QuerySubmitted`: extract the search index metadata
and call the correct `_Navigate()` function
## Validation Steps Performed
Search for...
- settings that don't change at runtime:
- [x] global settings
- [x] settings in profile.defaults
- [x] "add new profile" page
- settings that may change at runtime:
- [x] settings in a profile
- [x] individual color schemes
- [x] actions (main actions page + edit action subpage)
- [x] new tab menu folders
- [x] extensions
- misc. corner cases:
- [x] terminal chat (blocked in indexing script; requires minor changes
in feature branch)
- [x] settings in appearance objects
To test fzf matching and weighted results, I specifically tested these
scenarios:
- "PowerShell" --> prioritize the PowerShell profile page(s)
- "font size" --> prioritize profile defaults entry
- "font size powershell" --> prioritize PowerShell > font size
## PR Checklist
Closes#12949
## Follow-ups
- search by JSON key: need a way to add JSON keys to index entries.
`GetSearchableFields()` should make the rest pretty easy.
- search by keywords: need to define keywords. `GetSearchableFields()`
should make the rest pretty easy.
## Summary of the Pull Request
Pretty straightforward. Does exactly what it says on the tin.
## Validation Steps Performed
Pasting works when broadcast input is enabled...
✅ paste w/ mouse
✅ paste w/ keyboard (untouched)
Closes#18821
