This is just an idea. Tmux tabs don't have any associated processes,
so switching between them would raise debug logs all the time.
Not really an issue per se, so I'd be happy to just close this PR.
## Summary of the Pull Request
Added new localization for terminal and related code - Ukrainian.
## Detailed Description of the Pull Request / Additional comments
Based on `en-US` localization for terminal. Preserved formatting and
generic code style.
## Validation Steps Performed
## PR Checklist
- [x] Closes#19530
The actions page now has a list of all the commands (default, user,
fragments etc) and clicking a command from that page brings you to an
"Edit action" page where you can fully view and edit both the action
type and any additional arguments.
## Detailed Description of the Pull Request / Additional comments
Actions View Model
* Added several new view models
* `CommandViewModel` (view model for a `Command`), a list of these is
created and managed by `ActionsViewModel`
* `ActionArgsViewModel` (view model for an `ActionArgs`), created and
managed by `CommandViewModel`
* `ArgWrapper` (view model for each individual argument inside an
`ActionArgs`), created and managed by `ActionArgsViewModel`
Actions page
* No longer a list of only keybindings, instead it is a list of every
command Terminal knows about
EditAction page
* New page that you get to by clicking a command from the Actions page
* Bound to a `CommandViewModel`
* Allows editing the type of shortcut action and the command name
* Depending on the shortcut action, displays a list of additional
arguments allowed for the command with the appropriate templating (bool
arguments are switches, flags are checkboxes etc)
Closes#19019
This commit also ups the number of render failures that are permissible
to 6 (one try plus 5 retries), and moves us to use an exponential
backoff rather than a simple geometric one.
It also suppresses the dialog box in case of present failures for Stable
users. I feel like the warning dialog should be used for something that
the user can actually do something about...
Closes#15601Closes#18198
When run from SYSTEM account TSF seems to be unavailable. The only
missing step to handle that is check during initialization.
Not sure if fail after partial success in `Implementation::Initialize`
should also be gracefully handled.
Closes#19634
Support for DECRQCRA Request Checksum of Rectangular Area was added in
#14989, but left disabled at build time because it could be considered a
security risk.
In #17895, we unconditionally added a toggle for it to Terminal's
settings UI and settings schema (`compatibility.allowDECRQCRA`). For
users on Stable and Preview, it didn't actually enable anything. Whoops.
Since we have a way to turn it off (and in so doing, mitigate the risk)
in Terminal, it's high time for us to remove the feature gating.
Conhost doesn't support turning it off for now and so conhost can still
have it compiled out, as a treat.
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.
## Summary of the Pull Request
Fixes a bug where the dangling selection from a search would be applied
to the wrong position. Specifically, the issue is that
`SetSelectionAnchor()` and `SetSelectionEnd()` expect viewport positions
whereas the searcher outputs buffer positions.
This PR simply applies the scroll offset to the search result before
calling the functions.
In a separate iteration, I changed the functions to allow for
viewport-relative vs buffer-relative positions. However, that ended up
feeling a bit odd because this is the only scenario where the functions
were receiving buffer-relative positions. I chose this approach instead
because it's smaller/cleaner, even though we convert to
viewport-relative before the call just to change it to buffer-relative
in the function.
Bug introduced in #19550
## Validation Steps Performed
The correct region is selected in the following scenarios:
✅ no scrollback
✅ with scrollback, at bottom
✅ with scrollback, not at bottom (selection isn't scrolled to, but I
think that's ok. Can be fixed easily if requested)
✅ alt buffer
## 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
## Summary of the Pull Request
Fixes a bug where search would not scroll to results just below the
viewport.
This was caused by code intended to scroll the search result in such a
way that it isn't covered by the search box. The scroll offset is
calculated in `TermControl::_calculateSearchScrollOffset()` then handed
down in the `SearchRequest` when conducting a search. This would get to
`Terminal::ScrollToSearchHighlight()` where the offset is applied to the
search result's position so that we would scroll to the adjusted
position.
The adjustment was overly aggressive in that it would apply it to both
"start" and "end". In reality, we don't need to apply it to "end"
because it wouldn't be covered by the search box (we only scroll to end
if it's past the end of the current view anyways).
The fix applies the adjustment only to "start" and only does so if it's
actually in the first few rows that would be covered by the search box.
That unveiled another bug where `Terminal::_ScrollToPoints()` would also
be too aggressive about scrolling the "end" into view. In some testing,
it would generally end up scrolling to the end of the buffer. To fix
this cascading bug, I just had `_ScrollToPoints()` just call
`Terminal::_ScrollToPoint()` (singular, not plural) which is
consistently used throughout the Terminal code for selection (so it's
battle tested).
`_ScrollToPoints()` was kept since it's still used for accessibility
when selecting a new region to keep the new selection in view. It's also
just a nice wrapper that ensures a range is visible (or at least as much
as it could be).
## References and Relevant Issues
Scroll offset was added in #17516
## Validation Steps Performed
✅ search results that would be covered by the search box are still
adjusted
✅ search results that are past the end of the view become visible
✅ UIA still selects properly and brings the selection into view
## PR Checklist
Duncan reported this bug internally, but there doesn't seem to be one on
the repo.
Previously, launching an unelevated session after an elevated one would
delete the latter's persisted buffers, and vice versa of course. Also,
elevated buffers didn't have an ACL forbidding access to unelevated
users. That's also fixed now.
Closes#19526
## Validation Steps Performed
* Unelevated/elevated WT doesn't erase each other's buffers ✅
* Old buffers named `buffer_` are renamed to `elevated_` if needed ✅
## Summary of the Pull Request
Replaces the `ComboBox` used for built-in profile icons with an
`AutoSuggestBox` to allow for searching.
## References and Relevant Issues
Practically plagiarizes #16821
## Validation Steps Performed
✅ It completes
✅ It filters
## PR Checklist
Closes#19457
## Summary of the Pull Request
This PR fixes a bug where programmatic scrolling would get stuck. The
fix makes the "snap-on-input" feature conditional, activating it only
for modern applications that use Virtual Terminal (VT) processing. This
restores correct scrolling behavior for legacy applications without
removing the feature for new ones.
## References and Relevant Issues
Fixes#19390: OpenConsole: Cursor visibility prevents programmatic
scrolling
## Detailed Description of the Pull Request / Additional comments
The "snap-on-input" feature introduced in a previous PR caused an
unintended side effect for older console programs that use the
SetConsoleWindowInfo API to manage their own viewport. When such a
program tried to scroll using a key press, the snap feature would
immediately pull the view back to the cursor's position, causing the
screen to flicker and get stuck.
This fix makes the snap-on-input feature smarter by checking the
application's mode first.
## Validation Steps Performed
Compiled the minimal C++ reproduction case from issue #19390.
Ran the test executable inside the newly built OpenConsole.exe.
Confirmed that scrolling with the Up/Down arrow keys now works
correctly, even with a visible cursor. The view no longer flickers or
gets stuck when the cursor moves outside the viewport.
Closes#19390
## Summary of the Pull Request
Searching in terminal highlights all search results. However, those
results are considered separate from a selection. In the past, the
highlighted result would be selected, resulting in it being the initial
position for mark mode. Now that it's separate, mark mode doesn't start
there.
To fix this, there's 2 changes here:
1. When we exit the search, we now select the focused search result.
This becomes the initial position for mark mode.
2. When we're in the middle of a search and mark mode becomes enabled,
the focused search result becomes the initial position for mark mode.
With this change, mark mode's initial position is determined in this
order:
1. the position of an active selection
2. the position of the focused search result (if one is available)
3. the top-left position of the viewport (if there is a scrollback) (see
#19549)
4. the current cursor position
## Validation Steps Performed
Entering mark mode in scenario X results in a starting position of Y:
✅ selected text during a search --> selected text
- NOTE: this seems to only occur if you start a search, then manually
click on the terminal to bring focus there, but keep the search results
active
✅ performed a search and results are available -->focused search result
✅ performed a search and no results are available
- scrolled up --> top-left of viewport
- no scrollback --> cursor position
✅ performed a search, got results, then closed search --> focused search
result
Closes#19358
## Summary of the Pull Request
Updates mark mode so that it starts at the viewport's origin (top-left)
if we're not scrolled to the bottom. This is based on the discussion in
#19488.
## Validation Steps Performed
✅ scrolled at bottom --> mark mode starts at cursor
✅ scrolled up --> mark mode starts at cursor
Closes#19488
This PR moves the cursor blinker and VT blink rendition timer into
`Renderer`. To do so, this PR introduces a generic timer system with
which you can schedule arbitrary timer jobs. Thanks to this, this PR
removes a crapton of code, particularly throughout conhost.
## Validation Steps Performed
* Focus/unfocus starts/stops blinking ✅
* OS-wide blink settings apply on focus ✅
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
I looked as far back as I was able to find, and we've used the OutputCP
since at least Windows NT 3.51.
I think it has _never_ been correct.
At issue today is the GB18030-2022 test string, which contains the
following problematic characters:
* `ˊ` `U+02CA` Modifier Letter Acute Accent
* `ˋ` `U+02CB` Modifier Letter Grave Accent
* `˙` `U+02D9` Dot Above
* `–` `U+2013` En Dash
They cannot be pasted into PowerShell 5.1 (PSReadline).
It turns out that when we try to synthesize an input event (Alt down,
numpad press, Alt up **with wchar**) we are using their output codepage
65001. These characters, of course, do not have a single byte encoding
in that codepage... and so we do not generate the numpad portion of the
synthesized event, only the alt down and up parts!
This is totally fine. **However**, there is also a .NET Framework bug
(which was only fixed after they released .NET Core, and rebranded, and
the community stepped in, ...) finally fixed in .NET 9 which used to
result in some Alt KeyUp events being dropped from the queue entirely.
https://github.com/dotnet/runtime/issues/102425
Using the input codepage ensures the right events get synthesized. It
works around the .NET bug.
Technically, padding in those numpad input events is _also more
correct_.
It also scares me, because it has been this way since NT 3.51 or
earlier.
## Summary of the Pull Request
Updates the "firstWindowPreference" global setting to take 3 values:
"defaultProfile", "persistedLayout", and "persistedLayoutAndContent".
The legacy "persistedWindowLayout" is being interpreted as
"persistedLayoutAndContent".
The tricky part here is that we need to maintain support for the legacy
value as persisting the layout and content, even though the value's name
suggests that it should just support the layout and no content. To get
around this, I added "persistedLayout" and "persistedLayoutAndContent".
The enum map is manually constructed for `FirstWindowPreference` to
exclude the deprecated value. This prevents the legacy value from
leaking into the settings UI.
Functionally, the change to serialize the contents is simple.
`WindowEmperor::_persistState()`'s second parameter is used to serialize
the buffer. Rather than having it set to `true`, we set it to
`GlobalSettings().FirstWindowPreference() ==
FirstWindowPreference::PersistedLayoutAndContent`.
## Validation Steps Performed
✅ "persistedWindowLayout" is changed to "persistedLayoutAndContent"
Closes#18757
Whoops. Closes#18652
<DHowett> I chatted with Leonard to figure out why I kept
misunderstanding this PR. The key is that **this function should not
always return an existing window.** It's supposed to find an existing
window on the current virtual desktop, not literally any window
anywhere.
