## 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
## 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
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
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>
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)
This also moves the Ukrainian Preview release notes to Stable (which
wouldn't happen automatically) and updates them thanks to Serhii.
Co-authored-by: Serhii Pustovit <light.feel@gmail.com>
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
This pull request removes the feature flag blocking Atlas from being
built into conhost, and introduces a new one preventing Atlas from using
_custom shaders_ in conhost.
This prevents us from taking a new dependency on `d3dcompiler_47.dll`.
It also adds all the build rules necessary to link Atlas in properly.
It is worth noting that Atlas does not work in WinPE, because there's no
DXGI/D2D or anything of note.
- `SetThreadpoolTimer` is equivalent in every way to
`SetThreadpoolTimerEx` for our use case (we throw away the return value)
- `SetThreadDescription` is optional
This essentially rewrites `TerminalInput` from scratch.
There's significant overlap between what kind of information
the Kitty protocol needs from the OS and our existing code.
The rewrite allows us to share large parts of the implementation.
Closes#11509
## Validation Steps Performed
* `kitten show-key -m kitty` ✅
* US Intern. " + ' produces `\'` ✅
* Hebrew base keys produce Unicode ✅
* Hebrew AltGr combinations produce Unicode ✅
* French AltGr+Space produces U+00A0 ✅
* German AltGr+Decimals produce []{}... ✅
- Actions page: entries now stretch across the screen horizontally (to a
max of 1000) to be consistent with other settings pages
- Edit action page:
- `Keybindings` and `Additional arguments` are now top-aligned headers
- All arg templates now also stretch across the screen horizontally to
match how expanders look in the rest of the settings UI
## Validation Steps Performed
Everything still works. Screenshots below.
Similar to the `FontFaceBox`, show all the available shortcut actions
when the user clicks the `ShortcutActionBox`, and filter the results
based on the user's search query
We do not have good test coverage for the `WindowsInbox` build.
- ClipboardTest regressed with #19511
- DECRQCRA tests were not written for WindowsInbox
- FTCS marks tests were not written for WindowsInbox
After this PR:
Summary: Total=7182, Passed=7160, Failed=3, Blocked=0, Not Run=0,
Skipped=19
The 3 failing tests are in the integrity level FT, and they fail because
they expect to be run in an empty console window (the test reads buffer
output starting from 0, 0.)
