This is a partial fix for the Get-Credential issue. While investigating it, I found that the pseudoconsole window is not marked as being "owned" (in NTUSER) by the PID/TID of the console application that is "hosted" "in" it. Doing this does not (and cannot) fix `Get-Credential` failing in DefTerm scenarios.
ConsoleSetWindowOwner is one of the operations that can be done by a conhost to any window, and so the RemoteConsoleControl can call through to the Win32 ConsoleControl to pull it off.
I chose to add SetWindowOwner to the IConsoleControl interface instead of moving ConsoleControl::Control into the interface to reduce the amount of churn and better separate interface responsibilities.
References #14119
(cherry picked from commit 62ffa4ba41)
Service-Card-Id: 87207850
Service-Version: 1.15
This commit is just a slight refactor of `ConsoleProcessList` which I've noticed
was in a poor shape. It replaces iterators with for-range loops, etc.
Additionally this fixes a bug in `SetConsoleWindowOwner`, where it used to
default to the newest client process instead of the oldest.
Finally, it changes the process container type from a doubly linked list
over to a simple array/vector, because using linked lists for heap allocated
elements felt quite a bit silly. To preserve the previous behavior of
`GetProcessList`, it simply iterates through the vector backwards.
* All unit/feature tests pass ✅
* Launching a TUI application inside pwsh inside cmd
and exiting kills all 3 applications ✅
(cherry picked from commit 391abafc2e)
Service-Card-Id: 87207823
Service-Version: 1.15
This changeset consists of two parts:
* Refactor `PtySignalInputThread` to move more code from `_InputThread`
into the various `_Do*` handlers. This allows us to precisely control
console locking behavior which is the cause of this bug.
* Add the 1-line fix to `_DoSetWindowParent` to unlock the console before
calling foreign functions (`SetWindowLongPtrW` in this case).
This fix is theoretical in nature, based on a memory dump from an affected user
and most likely fixes: https://developercommunity.visualstudio.com/t/10199439
## Validation Steps Performed
* ConPTY tests complete. ✅
(cherry picked from commit 3c78e01ab5)
Service-Card-Id: 87207820
Service-Version: 1.15
#14160 didn't fix#14132 entirely. There seems to be a race condition left
where (on my system) 9 out of 10 times everything works correctly,
but sometimes OpenConsole exits, while pwsh and bash keep running.
My leading theory is that the new code is exiting OpenConsole faster than the
old code. This prevents clients from calling console APIs, etc. causing them
to get stuck. The old code (and new code) calls `ExitProcess` when the ConPTY
pipes break and I think this is wrong: In conhost when you close the window we
only call `CloseConsoleProcessState` via the `WM_CLOSE` event and that's it.
Solution: Remove the call to `RundownAndExit` for ConPTY.
During testing I found that continuously printing text inside msys2 will cause
child processes to only exit slowly one by one every 5 seconds.
This happens because `CloseConsoleProcessState` calls `HandleCtrlEvent` without
holding the console lock. This creates a race condition where most of the time
the console IO thread is the one picking up the `CTRL_CLOSE_EVENT`. But that's
problematic because the `CTRL_CLOSE_EVENT` leads to a `ConsoleControl` call of
type `ConsoleEndTask` which calls back into conhost's IO thread and
so you got the IO thread waiting on itself to respond.
Solution: Don't race conditions.
## Validation Steps Performed
* `Enter-VsDevShell` and close the tab
Everything exits after 5s ✅
* Run msys2 bash from within pwsh and close the tab
Everything exits instantly ✅
* Run `cat bigfile.txt` and close the tab
Everything exits instantly ✅
* Patch `conhost.exe` with `sfpcopy`, as well as `KernelBase.dll`
with the recent changes to `winconpty`, then launch and exit
shells and applications via VS Code's terminal ✅
* On the main branch without this modification remove the call to
`TriggerTeardown` in `RundownAndExit` (this speeds up the shutdown).
Run (msys2's) `bash.exe --login` and hold enter and then press Ctrl+Shift+W
simultaneously. The tab should close and randomly OpenConsole should exit
early while pwsh/bash keep running. Then retry this with this branch and
observe how the child processes don't stick around forever anymore. ✅
(cherry picked from commit b6b1ff8b2c)
Service-Card-Id: 87207831
Service-Version: 1.15
This is just a quick drive-by improvement. Switching from double to float
roughly doubles performance on a contemporary x86 CPU with `/fp:fast`.
## Validation Steps Performed
* Patch `RenderSettings.hpp` to include `Mode::AlwaysDistinguishableColors`
* Run a color intense application in AtlasEngine and observe CPU usage
(cherry picked from commit bbc14a0baf)
Service-Card-Id: 87207829
Service-Version: 1.15
When we added support for the `DECAC1` control sequence, which
determines whether `C1` controls are accepted or not, the intention was
that conhost would be making that determination, and Windows Terminal
would always be expected to accept any passed-through `C1` controls.
However, this didn't take into account that a passed-through `RIS`
sequence could end up disabling `DECAC1`, and that would leave Windows
Terminal incapable of processing any `C1` controls. This PR attempts to
fix that oversight.
The `DECAC1` sequence was added in PR #11690, when we disabled `C1`
acceptance by default.
This is a bit of a hack, but I've added a new `AlwaysAcceptC1` mode to
the state machine, which is enabled at startup in the Terminal, and is
never disabled. The parser then just needs to check whether either
`AcceptC1` or `AlwaysAcceptC1` are set.
## Validation Steps Performed
I've manually confirmed the test case in #13968 now works as expected.
Closes#13968
(cherry picked from commit f2b361c146)
Service-Card-Id: 87207769
Service-Version: 1.15
In the most recent compiler ingestion into Windows ("LKG14"), we found
that this particular construction--checking an optional for a value
during this range-for loop--resulted in bad code generation.
When optimized, it generates code that looks effectively like this:
```c++
if (!newRowWidth.has_value()) {
while (true) {
// do the row stuff...
++it;
}
}
```
The loop never exits, and `_RefreshRowIDs` walks off the end of the
buffer. Whoops.
This commit fixes that issue by tricking the optimizer to go another
way. Leonard tells me it's harmless to call `Resize` a bunch of times,
even if it's a no-op, so I trust that this change results in the right
outcome with none of the crashing.
Fixes MSFT-41456525
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 c2b3697c867bddf5660da8b222e99ff4bfd1ea5b
(cherry picked from commit 3c104440a8)
If the opacity is set to 100%, the background becomes solid instead of 'fully opaque acrylic'. If the opacity is below 100% the acrylic material is re-enabled (depending on the user's settings).
## Validation Steps Performed
I updated two unit tests to reflect the change in behavior and manually tested the transition from <100% opacity to 100% opacity (and vice versa) on win11.
Steps:
1. Start with 100% opacity and acrylic material enabled.
2. Decrease opacity and observe acrylic effect.
3. Increase opacity back to 100% and disable the acrylic effect.
4. Decrease opacity and notice that acrylic effect is no longer there.
Closes#12880
(cherry picked from commit 8ea3cb9972)
Service-Card-Id: 87207675
Service-Version: 1.15
This changeset includes various guards against resizing the terminal down to 0
columns/rows: The 2 `TextBuffer` locations that accept new sizes, as well as
the `HwndTerminal::Refresh` which was the entrypoint causing the issue.
Closes#14404
(cherry picked from commit c5d417fcaf)
Service-Card-Id: 87020510
Service-Version: 1.15
Watson reports show that Visual Studio terminal attempts to render a string that is null causing the renderer to crash.
More specifically, we see "NULL_POINTER_WRITE_c0000005_PublicTerminalCore.dll!TextBuffer::WriteLine" with the following stack:
PublicTerminalCore!TextBuffer::WriteLine+0x1da
PublicTerminalCore!TextBuffer::Write+0x191
PublicTerminalCore!Microsoft::Terminal::Core::Terminal::_WriteBuffer+0x1d3
PublicTerminalCore!Microsoft::Terminal::Core::Terminal::PrintString+0x9
PublicTerminalCore!TerminalDispatch::PrintString+0x22
PublicTerminalCore!Microsoft::Console::VirtualTerminal::OutputStateMachineEngine::ActionPrintString+0x42
PublicTerminalCore!Microsoft::Console::VirtualTerminal::StateMachine::ProcessString+0x123
PublicTerminalCore!TerminalSendOutput+0x68
Microsoft_DotNet_MSBuildSdkResolver!DomainBoundILStubClass.IL_STUB_PInvoke(IntPtr, System.String)+0x8f
Microsoft_Terminal_Wpf!Microsoft.Terminal.Wpf.TerminalContainer.Connection_TerminalOutput(System.Object, Microsoft.Terminal.Wpf.TerminalOutputEventArgs)+0x20
Microsoft_VisualStudio_Terminal_Implementation!Microsoft.VisualStudio.Terminal.TerminalWindowBase+<>c__DisplayClass59_0+<<BeginProcessingPtyData>b__0>d.MoveNext()+0x55f
Internal bug: [Bug 1614709](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1614709): [Watson] crash64: NULL_POINTER_WRITE_c0000005_PublicTerminalCore.dll!TextBuffer::WriteLine
Added a null check before PInvoking TerminalSendOutput.
Validated locally that the check prevents null strings from rendering.
(cherry picked from commit 79c47f64a2)
Service-Card-Id: 87175193
Service-Version: 1.15
We already were setting the automation properties on the expander, however, we were not setting it on the content when an expander was present. This change applies the automation properties to both the expander and the child content (i.e. TextBox).
Closes#13827
(cherry picked from commit 62b34cf6f7)
Service-Card-Id: 87207143
Service-Version: 1.15
Override the center on launch setting when a position is specified on the commandline.
## Validation Steps Performed
1. Set center on launch in the SUI.
2. Run `wtd` - the new window is centered.
3. Run `wtd --pos 100,200` - the new window is positioned at (100,200).
Closes#14176
(cherry picked from commit 42befa7b58)
Service-Card-Id: 87207150
Service-Version: 1.15
There is a condition which causes the console host process (conhost.exe)
to crash with a `FAIL_FAST` in `WriteCharsLegacy`.
**_Repro Scenario:_** Two conditions need to be met for crash to happen:
1. The `ENABLE_PROCESSED_OUTPUT` console mode needs to be disabled. This
condition is met through the race condition, explained in the section
below.
2. We are printing a string where there is a full width character
(character that requires two spaces on the screen) being printed at
the edge of the console window. That is, we have one character space
available, and the character requires 2 spaces.
Running following script (attached to bug) causes a crash:
`for /l %%A in (0, 1, 10000) do start /B C:\test.bat`
The script `test.bat` repeatedly prints a console-width line
with a DBCS character that doesn't fit.
_**Race:**_ Normally, we get into `WriteCharsLegacy` with
`PROCESSED_OUTPUT` enabled. However, during the initialization of a new
CMD session, `cmd!ResetConsoleMode()` is called, which first sets the
output console mode to the value of `curOutputMode` (which is a static
variable initialized to 0) by calling `SetConsoleMode()`, before then
setting it to the desired output mode with processed output enabled:
```c++
void ResetConsoleMode( void )
{
static DWORD desOutMode = ENABLE_PROCESSED_OUTPUT | /* ... */;
SetConsoleMode(conOut, curOutputMode); // <------ sets console mode to 0, disabling processed output
if (GetConsoleMode(conOut, &curOutputMode)) {
if ((curOutputMode & desOutMode) != desOutMode) {
curOutputMode |= desOutMode;
if (!SetConsoleMode(conOut, curOutputMode) && /* ... */) // <----- enables processed output
```
If there is another instance of CMD that is producing output in between
these two `SetConsoleMode()` calls, then we may end up in
`WriteCharsLegacy` with processed output mode disabled.
This fix removes a `FAIL_FAST_IF` that checks for `PROCESSED_OUTPUT`
mode after the initial character processing loop.
Before RS5, this was an `ASSERT()`. This FAIL_FAST was added in RS5 in
PR !1794053 (which changed all `ASSERT`-likes to `FAIL_FAST_IF`.)
We believe this assertion guarded only the "processing" of Backspace,
Tab, CR and LF, and did not expect that we would get out of the
character processing loop with unprocessed glyph characters. The
`FAIL_FAST` is redundant in this case, as the handlers for the
Backspace, Tab, CR and LF characters we are already checking for
`PROCESSED_OUTPUT`. Therefore, it is safe to remove this `FAIL_FAST`.
It turns out that we *can* exit the loop with unprocessed glyph
characters. In these cases, we don't want to `FAIL_FAST`.
# Validation
* Basic sanity testing to confirm strings are correctly being printed.
* Repro scenario script no longer crashes conhost.exe
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_we_adept_e4d2 eb5d8064dc0f09d8be92efb5e6efa69983f30a3f
Related work items: MSFT-42055103
(cherry picked from commit 86928bb48d)
The following members were not initialized during construction:
* `CursorType _defaultCursorShape`
* `bool _suppressApplicationTitle`
* `bool _bracketedPasteMode`
* `size_t _hyperlinkPatternId`
* `SelectionExpansion _multiClickSelectionMode`
* `til::CoordType _scrollbackLines`
Unlike gcc and clang, MSVC is fairly tame when it comes to removing code
tainted by undefined behavior, so the most likely affect this had is that
we were reading uninitialized memory.
Related to #14129.
(cherry picked from commit a798a603e1)
Service-Card-Id: 86826740
Service-Version: 1.15
Silent MIDI notes can be used to seemingly deny a user's input for long
durations (multiple minutes). This commit improves the situation by ignoring
all DECPS sequences for a second when Ctrl+C/Ctrl+Break is pressed.
Additionally it fixes a regression introduced in 666c446:
When we close a tab we need to unblock/shutdown `MidiAudio` early,
so that `ConptyConnection::Close()` can run down as fast as possible.
* In pwsh in Windows Terminal 1.16 run ``while ($True) { echo "`e[3;8;3,~" }``
* Ctrl+C doesn't do anything ❎
* Closing the tab doesn't do anything ❎
* With these modifications in Windows Terminal:
* Ctrl+C stops the output ✅
* Closing the tab completes instantly ✅
* With these modifications in OpenConsole:
* Ctrl+C stops the output ✅
* Closing the window completes instantly ✅
(cherry picked from commit b4fce27203)
Service-Card-Id: 86518584
Service-Version: 1.15
This removes all of the redundant tooltips from the settings UI. Since all of the settings are added through the SettingsContainer, it's a pretty simple change.
Closes#14184
- [X] hover over all settings in the settings UI
- [X] hover over all entries in the SUI nav view
(cherry picked from commit 3eaa781499)
Service-Card-Id: 86390068
Service-Version: 1.15
This PR by itself doesn't _really_ change much. Technically, now the Terminal will respect the Title of a `.lnk` when started for defterm, but we don't do anything else yet. Primarily, the goal of this PR is to just wire up startup info in OpenConsole to the connected Terminal.
* This required a bit of changes in `srvinit.cpp:ConsoleEstablishHandoff` to replicate other bits of startup, where we crack open the connect message to get the relevant bits of info.
* We pack that all into a `TERMINAL_STARTUP_INFO`, which we pass along to the registered terminal application.
* `ConptyConnection` accepts the handoff, and gathers that information out of the `TERMINAL_STARTUP_INFO`
* Some other updates to the scratch sln were made to make it build again (related, but unimportant).
* This is a precursor to:
* #13111
* #12154
* Closes#9458
* Tested manually
* I work here
(cherry picked from commit 7e47f6aab9)
Service-Card-Id: 86230565
Service-Version: 1.15
We'll just ping the window and give it a chance to respond before we
bunk with it.
Fixes#14131
(cherry picked from commit ab04067e49)
Service-Card-Id: 86230023
Service-Version: 1.15
It cannot be known why there is no site.
We should at least not crash.
Fixes MSFT-41571451
(cherry picked from commit 18e4e22394)
Service-Card-Id: 86206545
Service-Version: 1.15
Fix a missing entry in the JSON schema for `intenseTextStyle`.
The JSON schema was missing an entry in the Profile section for
`intenseTextStyle`. I have added it as it appears in AppearanceConfig.
Note that this is currently duplicated in the schema -- however, this is
the pattern used already in Profile as AppearanceConfig entries have
alternate descriptions (and I have updated the description in that
section to make it clear it applies to unfocused terminals).
Longer-term, it likely makes sense to consolidate all entires into
ApperanceConfig and rely on the description for the `unfocusedApperance`
object/the name of the object to make the limited scope of those keys
clear, so that Profile can simply extend ApperanceConfig and the
duplication in the schema can be reduced.
## Validation Steps Performed
Validation with schema verifying tools including VS Code.
Partially addresses #13387
(cherry picked from commit 33cb0eb05f)
Service-Card-Id: 86228742
Service-Version: 1.15
This pull request operates on the same theory as #14217, but at a lower
level. Carlos and I discovered that TerminalPage *already* has an
action-dispatching key preview handler, and that my implementation of
`IDirectKeyListener` handles focus-tree bubbling mostly correctly.
Because of that discovery, we learned we could move the
`IDirectKeyListener` into TerminalPage itself and not have to complicate
the SUI or the Command Palette with the DirectKey interface.
Validation:
When bound to Alt+Space, the system menu works in the command palette,
the settings UI, and in read-only panes.
Fixes#11970Closes#14217
Fixes MSFT-41390832
(cherry picked from commit d319d479c7)
Service-Card-Id: 86228469
Service-Version: 1.15
Problem:
* Calling `RundownAndExit` tries to flush out the last frame from `VtEngine`
* `VtEngine` indirectly calls `RundownAndExit` if the pipe is gone via `VtIo`
* `RundownAndExit` is called by other parts of OpenConsole
* `RundownAndExit` must be `[[noreturn]]` for most parts of OpenConsole
* `VtIo` itself has a mutex ensuring orderly shutdown
* In short, doing a thread safe orderly shutdown requires us to hold both,
a lock in `RundownAndExit` and `VtIo` at the same time, but while other parts
need a blocking `RundownAndExit`, `VtIo` needs a non-blocking one
* Refactoring the code to use optionally non-blocking `RundownAndExit`
requires refactoring and might prove to be just as buggy
Solution:
* Simply don't call `RundownAndExit` in `VtEngine` at all
* In case the write pipe breaks:
* `VtEngine` will close the handle
* The client should notice that their read pipe is broken and
close their write pipe sooner or later
* Once we notice that our read pipe is broken, we call `RundownAndExit`
* `RundownAndExit` might call back into `VtEngine` but
without a pipe it won't do anything
* In case the read pipe breaks or any other part calls `RundownAndExit`:
* We call `RundownAndExit`
* `RundownAndExit` might call back into `VtEngine` and depending on whether
the write pipe is broken or not it will simply write into it or ignore it
Closes#14132
Pretty sure this also applies to #1810
## Validation Steps Performed
* Open 5 tabs and run MSYS2's `bash --login` in each of them
* `Enter-VsDevShell` in another tab
* Close window
* 5 tab processes are killed instantly, 1 after ~3s ✅
* Replace conhost with OpenConsole via sfpcopy
* Launch Dozens of Git Bash tabs in VS Code
* Close them randomly
* Remaining ones still work, processes are gone ✅
(cherry picked from commit 1774cfd843)
Service-Card-Id: 86178271
Service-Version: 1.15
`ConptyClosePseudoConsole` blocks until OpenConsole exits.
This is problematic for the changes in 666c446, which stopped calling that
function on a background thread to solve a race condition. This commit fixes
the potential lags/deadlocks from waiting on OpenConsole's exit, by adding
`ConptyClosePseudoConsoleNoWait` which only closes the IO handles and allows
OpenConsole to exit naturally. This uncovered another potential deadlock
in `ServiceLocator::RundownAndExit` which might call itself recursively.
Closes#14032
## Validation Steps Performed
* Print tons of text and concurrently close the tab.
Tab closes, OpenConsole/pwsh exits instantly ✅
* Use `Enter-VsDevShell` and close the tab.
Tab closes instantly, OpenConsole/pwsh exits after ~5 seconds ✅
(cherry picked from commit 274bdb31da)
Service-Card-Id: 86209670
Service-Version: 1.15
c0b2f488c1
Unlike iTerm2, we're not planning on making it configurable.
This commit also adds a max length of 1024 characters on the "display URI" that we pass up to XAML, so as to not inundate the UI.
Fixes#14200
(cherry picked from commit 07201d6cd1)
Service-Card-Id: 86182617
Service-Version: 1.15
Instead of using the currently focused tab when an unfocused tab is duplicated, the `_MakePane(...)` function now uses an optional source tab argument that points to the correct tab being duplicated.
## Validation Steps Performed
Manually tested on multiple tabs with different profiles. Performed steps:
* Construct at least two tabs with different profiles.
* Select `Duplicate Tab` option from the dropdown menu of the unfocused tab.
* Verify that the new tab has the same profile as the tab it was duplicated from.
Closes#13942
(cherry picked from commit 8f08bb04d0)
Service-Card-Id: 86159036
Service-Version: 1.15
The breadcrumbs in the SUI were not readable by screen readers because they are represented as a button with a text block inside of it. Turns out, if you make the DataTemplate's item `IStringable` (meaning it has a `ToString()`), it all magically works! Allowing the screen reader to read the button as text.
Closes#13826
(cherry picked from commit 30046dd4a7)
Service-Card-Id: 86158951
Service-Version: 1.15
As noted by the `winrt::event` documentation:
> [...] But for asynchronous events, even after revoking [...], an in-flight
> event might reach your object after it has started destructing.
This is because while adding/removing/calling event handlers might be
thread-safe, there's no guarantee that they run mutually exclusive.
This commit fixes the issue by reverting 6f0f245. Since we never checked
the result of closing a terminal connection anyways, this commit simply drops
the wait on the connection being teared down to ensure #1996 doesn't regress.
Closes#13880
## Validation Steps Performed
* Open tab, close tab, open tab, close tab, open tab, close tab
* ConPTY ✅
* Azure ✅
* Closing a tab with a huge amount of panes ✅
* Opening a bunch of tabs and then closing the window ✅
* Closing a tab while it's busy with VT ✅
* `wtd -w 0 nt cmd /c exit` ✅
* `wtd -w -1 cmd /c exit`
* No WerFault spawns ✅
(cherry picked from commit 666c446bc3)
Service-Card-Id: 86178273
Service-Version: 1.15
Adds UIA events to the WPF control for the following items:
- selection changed
- text changed (and output)
- cursor changed
Similar to the architecture of the UWP TermControl, we added a
`HwndTerminalAutomationPeer` which acts as the
`TermControlAutomationPeer` in UWP. However, we don't need a XAML
wrapper here, so really we just need it to inherit from
`TermControlUiaProvider` (the `ITextProvider` implementation shared
across conhost and WT) and `IUiaEventDispatcher` (the event dispatching
interface that is responsible for signaling the screen reader that
something has changed).
As with WT, we need to record key events to remove the local echo. These
recorded events are matched up with the output text. Each sequential
match is removed in the output text so that it's not read by the screen
reader.
As with WT, a `UiaEngine` was added to the renderer and it is set up
when a UIA client is detected. WT would normally stop sending events
when focus was lost from the control. We do the same here.
`TermControlUiaProvider` was upgraded to support property values. Such
properties include class name and control type. These align with those
set in `TermControlAutomationPeer`. Realistically, those should point to
these, but that requires a lot more work and a localization burden
(because we need to move the localized word "terminal").
`HwndTerminalAutomationPeer` takes this a step further and overrides the
class name to be `WPFTermControl`. This allows screen readers to provide
special handling for the `WPFTermControl` vs the UWP term control since
they will be updating at different speeds.
To build the WPF test app, I had to mess with the dependencies a little
bit. Really just add the atlas engine and uia renderer to the build
steps.
The initialization order with `WM_NCCREATE` was changed to match that of
Windows Terminal (BaseWindow/IslandWindow). This is safer now. I also
removed the `static` window because it was unnecessary.
WPF's HwndHost likes to mark the `WM_GETOBJECT` message as handled to
force the usage of the WPF automation peer. We now explicitly mark it as
not handled and don't return an automation peer. This forces the message
to go down to the HwndTerminal where we return terminal's UiaProvider.
TermContol (the top-most layer in the UIA tree) would pop up and not do
anything. This PR also overrides the automation peer at that layer and
marks IsContentElement/IsControlElement=false (the equivalent to
AccessibilityView=Raw). This makes the layer only appear in the UIA tree
if you are using the raw view (i.e. you know what you're doing and you
want to see each individual layer even if you can't directly interact
with it).
Tested with Narrator/NVDA using WpfTerminalTestNetCore project in our
repo.
- [X] New output is read out (not just key events, but also other output
text)
- [X] Local echo does not occur (i.e. pressing 'A' should only read 'A'
once, not twice [key event and rendered letter]).
- [X] selection events are read out properly
- [X] cursor change events are read out properly (tested with text
cursor indicator preview in Settings App > Accessibility > Text
Cursor)
NOTE: test this with Release builds. Debug builds may be too slow and
not read out properly
Closes#12642
(cherry picked from commit 5608cf15a3)
Service-Card-Id: 86081128
Service-Version: 1.15
Paths that contain illegal path components will be dropped
in the dispatcher.
(cherry picked from commit fc0ef37977)
Service-Card-Id: 85900829
Service-Version: 1.15
When we first introduced the shell extension, it didn't work properly
for some folders (such as the Desktop, or perhaps any "background"
click) due to a bug in Windows. We worked around that bug with the help
of an awesome community member, who contributed code that would pull up
the topmost Explorer window and query its location.
That Windows bug was eventually fixed, but we still had trouble with
items appearing correctly. On Windows 11, the Open in Terminal menu item
appears and disappears at random when you right-click the desktop, but
it always appears when you right-click a folder. It sometimes appears
for Quick Access, even though it shouldn't.
We tried to fix that in #13206, but the fix caused more issues than it
solved. We reverted it for 1.15 and 1.16.
At the end of the day, it turns out that getting the path from the
toplevel explorer window is fragile. Fortunately, the shell does offer
us a way to get that information: the site chain.
This pull request replaces GetPathFromExplorer() with an implementation
of `IObjectWithSite`, which allows us to use the site chain to look up
from whence a context menu request was initiated. It also makes item
lookup generally more robust.
* ✅ Tested on Windows 11
* ✅ Desktop
* ✅ Folder Background
* ✅ Folder Selected
* ✅ Quick Access (does not appear)
* ✅ This PC (does not appear)
* ✅ Tested on Windows 10
* ✅ Desktop
* ✅ Folder Background
* ✅ Folder Selected
* ✅ Quick Access (does not appear)
* ✅ This PC (does not appear)
References #13206
References #13523Closes#12578
Co-authored-by: John Lueders <johnlue@microsoft.com>
(cherry picked from commit 5027c8031d)
Service-Card-Id: 85788408
Service-Version: 1.15
Added control in code for not allowed characters in the filename when saving a
tab.
Closes#13664
(cherry picked from commit 8721573957)
Service-Card-Id: 85487287
Service-Version: 1.15
Our Windows branch name changed, and I took this opportunity to resolve
an issue where vpack builds would occasionally fail due to GitHub rate
limiting the Azure DevOps IP addresses.
(cherry picked from commit 3958c938af)
Service-Card-Id: 85567588
Service-Version: 1.15
This commit reduces the amount of telemetry during general usage by about half.
8 events that weren't really used anymore were removed.
1 new event was added ("AppInitialized") which will help us investigate #5907.
During review 9 events were found that were incorrectly tagged as perf. data.
* Launch Windows Terminal
* The "latency" field "AppInitialized" matches the approx. launch time ✅
(cherry picked from commit 37c159abba)
Service-Card-Id: 85548958
Service-Version: 1.15
When Leonard updated CLI11 in #12658, he imported a version that no
longer requires RTTI. Since CLI11 was the only reason we had enabled
RTTI in any of our projects, we're finally able to turn it off.
| | TerminalApp.dll | MSIX Package |
| ------ | ---------------:| ------------:|
| Before | 3180KiB | 6545KiB |
| After | 1970KiB | 6426KiB |
| Delta | **-1210KiB** | **-119KiB** |
(cherry picked from commit e682cdad5e)
Service-Card-Id: 85546966
Service-Version: 1.15
Takes title from the tab instead of the TermControl
Closes#13909
(cherry picked from commit 2c341c8deb)
Service-Card-Id: 85427880
Service-Version: 1.15
The min/max/close buttons now use the same font glyphs used in Windows instead of paths.
They will also look different depending on whether you use Windows 10 or 11.
With certain scaling levels, the new fluent icons are always blurry on titlebars (win32, UWP, terminal).
I didn't check, but I assume that the glyphs will not be blurry on Windows 10 because they use the old font.
However, the glyps seem to have some alignment issues, making them even more blurry, and I'm not sure if I can fix that.
I looked into the minimize button problem:
* The UWP titlebar has 4px/5px, just like Terminal, but win32 titlebars have 5px/4px
* The new fluent icons have rounded caps, but the win32 minimize one doesn't (it's very subtle)
* The win32 minimize button is not blurry when the other buttons are
From this I presume that the minimize button is still using the old icon. So perhaps the Terminal/UWP vertical alignment is correct.
I was able to improve the rendering by wrapping the icon inside a Viewbox.
However, it won't perfectly match UWP, because scaling is calculated differently.
The icon width is 10px, which on 1.25x scaling would become 12.5px.
UWP titlebars truncate that to 12px, while Xaml renders that as 13px.
This is probably the best that can be done for now.
I found these icons [here](https://docs.microsoft.com/en-us/windows/apps/design/style/segoe-fluent-icons-font).
(cherry picked from commit 67f6b29d63)
Service-Card-Id: 85488527
Service-Version: 1.15
While having a debugger attached, opening the settings tab generates an
uncomfortable amount of exceptions. This change reduces this by a lot.
## Validation Steps Performed
* Icons still appear ✅
(cherry picked from commit 76a5ff143e)
Service-Card-Id: 85487971
Service-Version: 1.15
This commit fixes two race conditions:
* `SetPseudoWindowCallback` set the `_pseudoWindowMessageCallback`
callback after the Win32 message thread was already spawned.
This issue was fixed by instead using the `ServiceLocator` to get
a hold of the global `VtIo` instance which is created statically.
* `XtermEngine::SetWindowVisibility` was called without holding the
console lock. This issue was fixed by simply acquiring it first.
Closes MSFT:40913882
## Validation Steps Performed
* Add `IsConsoleLocked()` assertion in `VtEngine::_Write`
* Run Windows Terminal
* No assertion failures ✅
(cherry picked from commit 4f3afee728)
Service-Card-Id: 85487461
Service-Version: 1.15
Added control in code for not allowed characters in the filename when saving a
tab.
Closes#13664
(cherry picked from commit 8721573957)
Service-Card-Id: 85487287
Service-Version: 1.15
The debugging tools folks helpfully published PdbStr and SrcTool as
NuGet packages for us to take a dependency on! Now we can end this
wasteful practice once and for all...
NOTE: This change introduces a harmless error message at the end of
symbol indexing. Instead of printing out the list of mapped sources,
`srctool` will complain that `srcsrv.dll` is missing. This is only cosmetic.
(cherry picked from commit 5f3222b993)
Service-Card-Id: 85487966
Service-Version: 1.15
```
% .\tools\ReleaseEngineering\ServicingPipeline.ps1
Inferred servicing version 1.14
PICK f025c53dba: Remove the fallback to wsl.exe when HKCU\...\Lxss doesn't exist (#13436)
OK
```
(cherry picked from commit 16028dee8b)
Service-Card-Id: 85487931
Service-Version: 1.15
This PR moves the key handling for mark mode into a helper method that is then called before an action/key binding is attempted.
Epic: #4993Closes#13533
- Add custom keybinding to "down" arrow key
- in mark mode --> selection updates appropriately
- out of mark mode --> keybinding executed
Amended by DHowett to remove URL targeting features.
(cherry picked from commit 70313db246)
Service-Card-Id: 84711521
Service-Version: 1.15
This reverts commit f785168aac (PR #13244)
The error logged to NVDA was caused by the following line of code in `_getTextValue()`:
`THROW_HR_IF(E_FAIL, !bufferSize.IsInBounds(_start) || !bufferSize.IsInBounds(_end));`
NVDA would expand a text range to encompass the document in the alt buffer. This means that the "end" would be set to the dangling "endExclusive" point (x = left, y = one past the end of the buffer). This is a valid range!
However, upon extracting the text, we would hit the code above. The exclusive end doesn't actually point to anything in the buffer, so we would falsly throw `E_FAIL`.
Though this could be fixed by adding a special check for the `endExclusive` in the line above, I suspect there are other places throughout the UIA code that hit this problem too. The safest course of action is to revert this commit entirely since it was a code health commit (it doesn't actually close an issue).
Closes#13866
(cherry picked from commit bfd5248a2e)
Service-Card-Id: 85405833
Service-Version: 1.15
This is conjecture - I was totally unable to repro the original crash here.
Based on the stacks in MSFT:39994969, it looks like we try to fire off a
`RaiseAutomationEvent`, which calls through UIA core, eventually to the point of
calling `ComPtr<WUX::Automation::Peers::IAutomationPeer>::{dtor}`. I'm guessing
based on the stacks that the TermControl has already been released and cleaned
up. However, the lambda in the `RunAsync` calls here only takes a ref to the
TCAP. The TCAP has an outstanding reference (maybe on the other side of the UIA
fence), and gets successfully resolved as strong, but when calling to
`RaiseAutomationEvent`, the `owner` we passed in is gonezo.
This explicitly passes a `weak_ref` to `TermControlAutomationPeer`, rather than
a raw ptr, so we can actually check if the control is still alive before _we_
dereference it. If it is, great, we've got a strong ref to it now and it won't
get torn down.
Again, this is hearsay. Without a repro, the only way we can confirm this is
gone is by just hoping the crashes go away. 🤞
* Might close#13357 (we'll reopen if it doesn't?)
* narrator still works
(cherry picked from commit fe0d57071e)
Service-Card-Id: 85401131
Service-Version: 1.15
Since locking the console can take a non-trivial amount of time,
the main thread might have already released the ControlCore instance, while the
`UpdatePatternLocations` background thread is holding the last active reference.
If the function call goes out of scope, we destroy the instance, which might
not be safe, considering its members are usually only used by the main thread.
This commit fixes the issue by only holding a reference of the `Terminal`.
## Validation Steps Performed
* Patterns are recognized ✅
(cherry picked from commit 12122b2bf9)
Service-Card-Id: 85321064
Service-Version: 1.15
See https://github.com/microsoft/terminal/issues/12176#issuecomment-1199488906, and MSFT:39723014.
I have literally no idea how to repro this one, or debug it. The dump I looked at looked like there was a `SwapChainScaleChanged` that was being dispatched as the app was tearing down. The `ControlCore` had started closing, but the `TermControl` hadn't yet. Apparently, just none of the `_refreshSizeUnderLock` callers checked if we were already closing.
All the callers appear to be on the main thread.
Closes#12176
Since there's no real way for me to repro this manually, I'm thinking we fire this fix off to the OS terminal build, where we'll pretty quickly be able to see if this fixed it or not.
(cherry picked from commit a85d9e69ed)
Service-Card-Id: 85321070
Service-Version: 1.15
## Summary of the Pull Request
The command palette (and tab search by extension) doesn't ever tell screen readers what is selected. Here, we simply hook up the selection changed event to a function that tells the screen reader what is selected. With this, the user no longer has to tab into the list view to know what is selected!
Will resolve the following bug upon validation from a11y team: #12065
## Validation Steps Performed
Performed repro steps from #12065.
NOTE: we do NOT read the selected item when the command palette is first opened. I think that's ok.
(cherry picked from commit deb5e7c650)
Service-Card-Id: 85254984
Service-Version: 1.15
I got tired of renaming the packages that came out of our build
pipeline. I also got tired of the fact that every appxbundle artifact we
upload comes with another whole copy of Terminal for every architecture,
plus all their symbols. Those are reflected in other artifacts, so
there's no reason to duplicate them.
(cherry picked from commit 623a59ecaa)
Service-Card-Id: 85252798
Service-Version: 1.15
Apparently, calling `GetText(INT_MAX)` causes a HUGE memory spike for a few seconds each time this is called. The [UIA docs](https://docs.microsoft.com/en-us/windows/win32/api/uiautomationcore/nf-uiautomationcore-itextrangeprovider-gettext#parameters) say to put `-1` if no limit is required, but I assume a few people have been hit by this before.
This addresses this issue (and similar ones) in two ways:
1. as we iterate over the lines of text, if we're already past the max length, just break out of the loop
2. _only_ resize if the max length is actually less than the current length. This prevents us padding the string with `L'\0'` erroneously (which is probably what causes the memory spike).
(cherry picked from commit b4ada09776)
Service-Card-Id: 85252534
Service-Version: 1.15
In #13024, we removed `Terminal::GetCursorPosition` from TerminalCore.
This has been widely regarded as a good move.
Now, you might rightly be wondering: why didn't compilation immediately
fail? Well. It turns out that there were _two_ copies of
`GetCursorPosition`. One for `const Terminal`, and one for `Terminal`.
This is important.
`Terminal::GetCursorPosition()` returned the cursor position relative to
the viewport. `Terminal::GetCursorPosition() const`, however, returns
the cursor position in absolute.
We removed the non-`const` one. Fortunately, thanks to the lookup rules
for `const`-qualified members, this didn't matter. Code that called
`GetCursorPosition()` still called `GetCursorPosition()`, and everything
was fine.
Except that part about the relative coordinates. That was not fine.
The TSF control is the _only_ consumer of `ControlCore.CursorPosition`,
and that was the _only_ consumer of relative-`GetCursorPosition()`.
This commit restores equilibrium by introducing a new
`GetViewportRelativeCursorPosition()` member to `Terminal` and switching
over the only consumer of relative cursor position to use it.
Closes#13769.
(cherry picked from commit 2dedc9af7f)
Service-Card-Id: 85131461
Service-Version: 1.15
Fixes MSFT:38775539
Might also fix MSFT:38614563
Looking at this code should be pretty clear what's going on. On exit, the XAML root is already nulled out. But here, we're just yolo'ing and assuming it exists (why wouldn't it). So yea. This is like weirdly high percent of crashes internally, but that's not from real users. Real users, I suspect hit this as like .3% of our crashes. Not zero, but _low_.
* [x] tested manually
<hr>
May also be related to...
* MSFT:40602905
* MSFT:40602904
* MSFT:40412800
* MSFT:35213459 <---has links
(cherry picked from commit 64bcc0bd25)
Service-Card-Id: 85486788
Service-Version: 1.15
Fixes MSFT:40853556
There's a small race here. The renderer thread in ConPTY might notice the terminal is gone, call CloseOutput, and release the vt renderer, and then the window proc fires and decides to minimize/restore the window, triggering an A/V.
I'm 100% confident that this has NEVER happened to a real user. But the test labs hit it so much that it makes up ~26% of our crashes.
I haven't tested this cause again, _it doesn't hit in the wild_
(cherry picked from commit f58240c9c0)
Service-Card-Id: 85103518
Service-Version: 1.15
Does two things:
* the first two commits: shakes up the way we reference MUX in our projects so we can actually just
```xml
<PropertyGroup Label="NuGet Dependencies">
<TerminalMUX>true</TerminalMUX>
</PropertyGroup>
```
Like every other dependency we have
* the last commit: update to MUX.2.7.3
This is the 1.14 PR, which should be appropriately cherry-picked through to `release-1.15` and `main`
(cherry picked from commit a277b56f6a)
Service-Card-Id: 85036583
Service-Version: 1.15
This commit builds directly on the changes made in #13677 and fixes:
* TSF resetting to AlphaNumeric ("ASCII") input mode when pressing enter
* Vietnamese IME not composing a new word after pressing whitespace, etc.
Closes#11479Closes#13398
## Validation Steps Performed
* Japanese IME (Full-Width Katakana)
Typing "saitama" produces "サイタマ" ✅
* Korean IME
Typing "gksrmf" produces "한글" ✅
* Vietnamese IME
Typing "xin chaof" produces "xin chào" ✅
* Emoji Picker (Win+.)
✅
(cherry picked from commit ed800dc72d)
Service-Card-Id: 84832470
Service-Version: 1.15
While working on #13398 I felt that `TSFInputControl` wasn't up to sniff.
This commit is a minor cleanup of the class:
* default member initializers
* Simplified use of STL classes which already perform boundary checks
* Correctly check text buffer emptiness in `_SendAndClearText`
* Track selection range as mandated by the API
## Validation Steps Performed
* Japanese IME (Full-Width Katakana)
Typing "saitama" produces "サイタマ" ✅
* Korean IME
Typing "gksrmf" produces "한글" ✅
* Vietnamese IME
Typing "xin chaof" continues to produce broken "xin xinchaof"
(It's supposed to produce "xin chào")
* Emoji Picker (Win+.)
✅
(cherry picked from commit 2c922e105c)
Service-Card-Id: 85034073
Service-Version: 1.15
We have a number of theories why #12607 is happening, one of which is that
some GPU drivers somehow rely on Win32 messages or similar which we process
on the main thread. If we then try to acquire the console lock on the main
thread, while the GPU-driver thread itself is holding that lock, we've got
ourselves a deadlock. This PR makes this less likely by running the repeat
offender `UpdatePatternLocations` on a background thread instead.
We have a number of other locations which acquire the console lock on the
main thread and a thorough bug fix must be done in a different way.
## Validation Steps Performed
* After pasting an URL it gets underlined on hover ✅
(cherry picked from commit 23e4d313d5)
Service-Card-Id: 85033019
Service-Version: 1.15
Due to the way our localization pipeline works, we cannot delete
resources in main until the resources in question are totally flushed
out of the active-servicing release branches. Unfortunately, in #13179,
we _did_ remove resource keys. Because the Color Schemes page in 1.14
and 1.15 uses the resources directly (rather than by way of x:Uid), it
is easier for us to backport the resource changes now than to
reintroduce the old keys on main.
Closes#13606
This commit simplifies `Jumplist::UpdateJumplist` by using exceptions
instead of returning error codes. Otherwise the code is identical to before.
(cherry picked from commit 768d4b59ca)
Service-Card-Id: 84836267
Service-Version: 1.15
- We only ever have 1 color picker now, instead of each tab having its own
- `TerminalPage` constructs this color picker (upon first request for it)
- `TerminalPage` attaches the color picker to the tab that requested for it
- `TerminalTab` detaches the color picker when it is done with it, so that `TerminalPage` can attach it to another tab later on
User-end behaviour is the same
(cherry picked from commit ba08dd2174)
## Summary of the Pull Request
In #13560 we added a member to `Pane` that lets it know if it was spawned as a default terminal session, but did not propagate that value when the pane gets split or when the pane closes. This commit fixes that.
## Validation Steps Performed
A session spawned by a def term invocation remembers it even as it goes through splits
(cherry picked from commit 1a7783449c)
Service-Card-Id: 84836635
Service-Version: 1.15
This is an experiment, as discussed in https://github.com/microsoft/terminal/issues/11790#issuecomment-1179143049. We don't know what for sure causes these crashes, but it seems that blindly throwing, so that it gets picked up by Watson, is probably not the move. Instead, we're just gonna do our fallback, REGARDLESS of what the exception was.
See #11790, MSFT:38542548, MSFT:38572983, MSFT:38542574 et. al.
(cherry picked from commit 5c35a64bb3)
Service-Card-Id: 84836297
Service-Version: 1.15
Refer to https://docs.microsoft.com/en-us/windows/win32/rstmgr/guidelines-for-applications
The OS will send us a WM_QUERYENDSESSION when it's preparing an
update for our app. It will then send us a WM_ENDSESSION, which gives
us a small timeout (~30s) to actually shut down gracefully. After
that timeout, it will send us a WM_CLOSE. If we still don't close
after the WM_CLOSE, it'll force-kill us (causing a crash which will be
bucketed to moapphang).
We will manually start a quit, so that we can persist the state. If we refuse to
gracefully shut down, the OS will crash us to focefully terminate us. We
choose to quit here, rather than just close, to skip over any warning dialogs
(e.g. "Are you sure you want to close all tabs?") which might prevent a WM_CLOSE
from cleanly closing the window.
This will cause a appHost._RequestQuitAll, which will notify the
monarch to collect up all the window state and save it.
This "crash" caused by the OS force killing us constitutes 80% of all our crashes. 80%. See MSFT:38947155, MSFT:38877540, MSFT:21058878, MSFT:31710054, MSFT:39764652, MSFT:26883776.
Closes#13569
It also fixes the issue where if you've got Terminal Dev running (outside VS), and you try to Deploy, you have to make sure to close the "Are you sure you want to close all tabs" dialog before the deployment can proceed. A deploy in VS sends the same sequence of messages as a real update.
(cherry picked from commit b3604ba0eb)
Service-Card-Id: 84836638
Service-Version: 1.15
## Summary of the Pull Request
Adds a new mode to `CloseOnExit`: `Automatic`. In this mode, if a process handed off by defterm terminates for whatever reason, we always close (i.e. we treat the mode as `Always`), but for processes launched by Terminal we terminate as with the `Graceful` behaviour.
## PR Checklist
* [x] Closes#13325
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
- Adds a new enum value to `CloseOnExit`
- Adds a new function to `Pane`: `FinalizeConfigurationGivenDefault`: this is a function that should be called when the pane is created via default terminal handoff, and can contain any special configurations we should set given that the pane was created via handoff
## Validation Steps Performed
(cherry picked from commit 89d57e827e)
Service-Card-Id: 84836029
Service-Version: 1.15
We must use 65535 as `MAX_PARAMETER_VALUE` in order for us to properly parse
win32-input-mode sequences, which transmit UTF-16 characters as parameters.
Closes#12977
## Validation Steps Performed
* Call `SendInput` with 🙁 (`L'\xD83D'`, `L'\xDE41'`)
* 🙁 appears on the input line ✅
(cherry picked from commit 74cdffe921)
Service-Card-Id: 84772549
Service-Version: 1.15
Curiously, at least on Windows 10 (and rarely on Windows 11), if you minimize the Terminal by clicking on the taskbar, then alt-tab to try and restore the window, the Taskbar will decide to call `SwitchToWindow` on the invisible, owned ConPTY window instead of the main window. When that happens, ConPTY'll get a `WM_SIZE(SIZE_RESTORED, lParam=0)`. The main window will NOT get a `SwitchToWindow` called. If ConPTY doesn't actually inform the hosting process about this, then the main HWND might stay hidden.
* Refer to #13158 where we disabled this.
* Closes#13589
* Closes#13248
* Tested manually on a Windows 10 VM.
* Confirmed that opening tabs while maximized/snapped doesn't restore down.
* `[Native]::ShowWindow([Native]::GetConsoleWindow(), 6)` still works
(cherry picked from commit d1fc11248c)
Service-Card-Id: 84673887
Service-Version: 1.15
On occasion, when we submit to the store we get a package rejection
because the app name has changed for the `qps-*` locales. Instead of
constantly reserving new pseudolocalized app names every time the
pseudolocalization seed changes, we should just lock our app name so
that it does not get pseudolocalized.
(cherry picked from commit bb40efc00b)
Service-Card-Id: 84417902
Service-Version: 1.15
Adds `ScrollToPoint()` from #13405 to be able to scroll to the selection marker when (1) mark mode is entered and (2) `selectAll` is called.
This change is a combination of #13656 and a minor part of #13405.
Epic: #4993
## Summary of the Pull Request
The original `DECPS` implementation made use of the Windows MIDI APIs to
generate the sound, but that required a 3MB package dependency for the
GS wavetable DLS. This PR reimplements the `MidiAudio` class using
`DirectSound`, so we can avoid that dependency.
## References
The original `DECPS` implementation was added in PR #13208, but was
hidden behind a velocity flag in #13258.
## PR Checklist
* [x] Closes#13252
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #13252
## Detailed Description of the Pull Request / Additional comments
The way it works is by creating a sound buffer with a single triangle
wave that is played in a loop. We generate different notes simply by
adjusting the frequency at which that buffer is played.
When we need a note to end, we just set the volume to its minimum value
rather than stopping the buffer. If we don't do that, the repeated
starting and stopping tends to produce a lot of static in the output. We
also use two buffers, which we alternate between notes, as another way
to reduce that static.
One other thing worth mentioning is the handling of the buffer position.
At the end of each note we save the current position, and then use an
offset from that position when starting the following note. This helps
produce a clearer separation between tones when repeating sequences of
the same note.
In an ideal world, we should really have something like an attack-decay-
sustain-release envelope for each note, but the above hack seems to work
reasonably well, and keeps the implementation simple.
## Validation Steps Performed
I've manually tested both conhost and Terminal with the sample tunes
listed in issue #8687, as well as a couple of games that I have which
make use of `DECPS` sound effects.
(cherry picked from commit bc79867b38)
Service-Card-Id: 84270205
Service-Version: 1.15
Does what it says on the tin. When we get focused, temporarily turn off readonly mode, as to not pop the dialog when the focus sequence is eventually sent to the connection.
* closes#13461
(cherry picked from commit b4a52c847f)
Service-Card-Id: 84111371
Service-Version: 1.15
## Summary of the Pull Request
When the debug tap converts control characters into visible glyphs, it
ends up losing the structure of the output, and that can sometimes make
things difficult to read. This PR attempts to alleviate that problem by
reinjecting an actual line break in the debug stream whenever an `LF`
control is received.
## PR Checklist
* [x] Closes#12312
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #12312
## Validation Steps Performed
I've tested the updated debug tab with a number of different shells, and
also a couple of different apps. When there aren't many linefeeds in the
output, it's obviously not going to make much of a difference, but when
there are, I think it definitely improves the readability.
(cherry picked from commit 04478d1df0)
Service-Card-Id: 84116395
Service-Version: 1.15
If launch mode is set to full screen quake window is opened in full
screen.
## Validation Steps Performed
- Set startup > launch mode > full screen
- Launch quake window
- Quake window shouldn't be opened in full screen
Closes#12894
(cherry picked from commit 589286a357)
Service-Card-Id: 84116410
Service-Version: 1.15
In non-en-us locales, these tooltips can get really long and get clipped.
Closes MSFT:39603031
See Also #9913
(cherry picked from commit 32379c29f0)
Service-Card-Id: 84008282
Service-Version: 1.15
## Summary of the Pull Request
When you create a console alias that overrides an existing command, it
should still be possible to execute the original command by prefixing it
with a space. However, at some point in the past, there was an attempt
to improve the usability by trimming leading spaces, and that ended up
breaking this functionality. This PR reverts that change, so leading
spaces can once again be used to bypass an alias.
## PR Checklist
* [x] Closes#4189
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #4189
## Validation Steps Performed
I've updated the existing alias unit test for leading spaces to match
the new behavior, i.e. it now confirms that a command with leading
spaces will not match the alias.
I've also manually confirmed that the `doskey` test case reported in
issue #4189 is now working as expected.
(cherry picked from commit cd2166aedf)
Service-Card-Id: 84072860
Service-Version: 1.15
This one's pretty obvious. I added another scrollbar sized grid to the terminal,
but I forgot to collapse it when the user requests `"scrollbarState": "hidden"`.
* [x] Closes#13446
* [x] I work here
(cherry picked from commit aa4e9f5414)
Service-Card-Id: 83969639
Service-Version: 1.15
The hover tab color used to be generated from the selected tab color, which would end up lighter or darker, and white-gray colors would end up pink.
It is now simply the selected tab color with 60% opacity. This is also how brushes are created for accent buttons and color buttons (although with different opacity levels).
(cherry picked from commit c6b67aad4b)
Service-Card-Id: 83894208
Service-Version: 1.15
The main result of this fallback is that we attempt to launch wsl.exe
when the user hasn't installed or interacted with WSL. On our test
machines, that results in the creation of a wsl.exe process that tells
us precisely nothing; on WDAC managed machines it results in an Event
Log entry about spawning another (possibly blocked) process.
The registry is more reliable, and if the "API" it provides changes we
can just rev terminal.
Closes#11716
(cherry picked from commit f025c53dba)
Service-Card-Id: 83892844
Service-Version: 1.15
## Summary of the Pull Request
In #13370, we should be notifying the renderer that the selection changed. Minor oversight and simple fix.
## References
#4993#13370Closes#13413
(cherry picked from commit 66ecb0bd63)
Service-Card-Id: 83892665
Service-Version: 1.15
This commit fixes a minor race condition covered as part of #13368.
The member `_pfnHandoff` was read without the mutex `_mtx` being locked first.
The issue was solved by acquiring the lock early and running the entire
`s_StopListening` function with that lock held.
(cherry picked from commit 95a19624a4)
Service-Card-Id: 83893126
Service-Version: 1.15
Update schema with the settings/actions added in #12948
## PR Checklist
* [x] Closes#13404
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Schema updated.
(cherry picked from commit 478c2c3613)
Service-Card-Id: 83790285
Service-Version: 1.15
## Summary of the Pull Request
Introduces the `switchSelectionEndpoint` action which switches whichever selection endpoint is targeted when a selection is present. For example, if you are targeting "start", `switchSelectionEndpoint` makes it so that now you are targeting "end". This also updates the selection markers appropriately.
## References
Spec - #5804#13358Closes#3663
## Detailed Description of the Pull Request / Additional comments
Most of the code is just standard code of adding a new action. Other than that, we have...
- if there is no selection, the action fails and the keybinding is passed through (similar to `copy()`)
- when we update the selection endpoint, we need to also update the "pivot". This ensures that future calls of `UpdateSelection()` respect this swap.
- [Corner Case] if the cursor is being moved, we make it so that you basically "anchored" an endpoint and you don't have to hold shift anymore.
## Why is this change being made?
Our conhost OneCore backend isn't as thoroughly tested as our Win32 one and fell victim to the general "bugginess" of our shutdown handling centered around `ServiceLocator::RundownAndExit`. In the past we simply leaked all resources, but changed it so that a cleanup on exit occurs, so that we can track resource leaks for instance. This broke OneCore which has a more delicate shutdown than Win32.
## What changed?
This commit reverts changes being made in 9d7a46f64c and after.
## How was the change tested?
This change was tested in a OneCore VM by repeatedly spawning subprocesses and ensuring they exit in a timely manner and without unexpected crashes.
Related work items: MSFT-40226902, MSFT-22128499
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 0683758a0846aefbbe50730c3cd336623328ddeb
## Summary of the Pull Request
1. [copy on select] when manually copying text (i.e. kbd or right-click) while in mark/quick-edit mode, we now dismiss the selection.
2. `Enter` is now bound to copy by default.
- This works very well with mark mode and provides a more consistent behavior with conhost's selection experience overall.
- "why not hardcode `Enter` as a way to copy when in mark mode?"
- In an effort to make this as configurable as possible, I decided to make it a configurable keybinding, but am open to suggestions.
3. selection markers
a. we now hide the selection markers when multi-clicking the terminal.
b. selection markers are now properly shown when a single cell selection exists
- Prior to this PR, any single cell selection would display both markers. Now, we actually track which endpoint we're moving and display the appropriate one.
4. ensures that when you use keyboard selection to move past the top/bottom of the scroll area, we clamp it to the origin/bottom-right respectively. The fix is also better here in that it provides consistent behavior across all of the `_MoveByX` functions.
5. adds `toggleBlockSelection` to the schema
## References
#13053
## Validation Steps Performed
Did a whole flowchart of expected behavior with copy on select:
- enable `copyOnSelect`
- make a selection with the mouse
- ✅ right-click should copy the text --> clear the selection --> paste
- use keyboard selection to quick-edit the existing selection
- ✅ `copy` action should clear the selection
- ✅ right-click should copy the text --> clear the selection --> paste
Played with selection markers a bit in mark mode and quick edit mode. Markers are updating appropriately.
FabricBot is now a [config-as-code-only] platform. As a result, while
you can still use the [FabricBot Configuration Portal] to modify your
FabricBot configuration, you can no longer save the changes. The only
way to save changes to your configuration at the moment is to _export
configuration_ from the portal and upload the exported configuration to
`.github/fabricbot.json` in your repository. In this pull request, we
are adding your FabricBot configuration to your repository at
`.github/fabricbot.json` so that you can make changes to it going
forward.
While the [FabricBot Configuration Portal] is the *only way* to modify
your FabricBot configuration at the moment, we have a feature on our
backlog to publish the JSON schema defining the structure of the
FabricBot configuration file. With the JSON schema, you can (1) use a
plaintext editor of your choice to modify the FabricBot configuration
file and use the schema to validate the file after editing or (2)
[configure VS Code] to use the schema when editing FabricBot
configuration file to take advantage of convenience features such as
automatic code completion and field description on mouseover.
[config-as-code-only]: https://eng.ms/docs/products/1es-data-insights/merlinbot/extensions/bot-config-as-code
[FabricBot Configuration Portal]: https://portal.fabricbot.ms/bot/?repo=microsoft/terminal
[configure VS Code]: https://code.visualstudio.com/Docs/languages/json#_json-schemas-and-settings
Co-authored-by: msftbot[bot] <48340428+msftbot[bot]@users.noreply.github.com>
Co-authored-by: Dustin Howett <duhowett@microsoft.com>
## Summary of the Pull Request
Replaces most uses of `Viewport::CompareInBounds()` with `til::point`'s `<` and `>` operators. `CompareInBounds` has been the cause of a bunch of UIA crashes over the years. Replacing them entirely ensures that the `FAILFAST_IF` isn't ever touched.
Unfortunately, we still need `IncrementInBounds` and `DecrementInBounds` to have support for that exclusive end.
## References
#13183
This commit fixes a bug causing the OpenConsole to get increasingly larger
every time the font is changed when the AtlasEngine is active.
The only impact this bug had on Windows Terminal is that the
`font-size` in HTML and RTF selection copies are too large.
## Validation Steps Performed
* OpenConsole window size doesn't change when
switching between main and alt buffer ✅
[Git2Git] Merged PR 7517171: Fix a race condition in ServiceLocator::RundownAndExit
The whole premise of RundownAndExit is that one thread enters it, runs
down the console and terminates it. One thread enters, 0 threads leave.
After some recent console locking changes, we found that on OneCore
devices it was possible for two threads (the I/O thread and the coniosrv
Input thread) to try to rundown and exit at the same time.
This SRWLOCK prevents that from happening.
Fixes#40146639
Related work items: #40146639 Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev ff235c6e49e065bccc937dee91f43ff310b5743c
Related work items: #40146639
[Git2Git] Merged PR 7517072: conhost: Force the double-click tests to have a high click timeout
The conhost tests might run somewhere that does not have a double click time.
We should hardcode a value for the purposes of testing.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 3c2620dab577e16e8672b369e4dfcde7c02881a1
Related work items: MSFT-40150725
This introduces the build rules for midi.lib to the OS!
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev fb066544f112ae491bb1d1f73578bc47fa167b41
In #6810, we introduced a "quirk" for all known versions of PowerShell
that suppressed their requests for black background/gray foreground.
This was done to avoid an [issue in PSReadline] where it would paint
black bars all over the screen if the default background color wasn't
the same as the ANSI black color.
Years have passed since that quirk was introduced. The underlying bug
was fixed, and the fix was released broadly long ago. It's time for us
to remove the quirk... almost.
Terminal still runs on versions of Windows that ship a broken version of
PSReadline. We must maintain the quirk there -- the user can't do
anything about it, and we would make their experience worse if we
removed the quirk entirely.
PowerShell 7.0 also ships a broken version of PSReadline. It is still in
support for another 6 months, but updates have been available for some
time. We can encourage users to update.
Therefore, we only need the quirk for Windows PowerShell, and then only
for specific versions of Windows.
_Inside Windows_, we don't even need that: we're guaranteed to be built
alongside a fixed version of PowerShell!
Closes#6807
[issue in PSReadline]: https://github.com/PowerShell/PSReadLine/issues/830#issuecomment-650508857
## Summary of the Pull Request
Introduced in #10824, this fixes a bug where you could use keyboard selection to move below the scroll area. Instead, we now clamp movement to the mutable viewport (aka the scrollable area). Specifically, we clamp to the corners (i.e. 0,0 or bottom right cell of scroll area).
## Validation Steps Performed
✅ (no output) try to move past bottom of viewport
✅ (with output, at bottom of scroll area) try to move past viewport
✅ (with output, NOT at bottom of scroll area) try to move past viewport
✅ try to move past top of viewport
It's not useful to notify users that WT can be made the default if it's already
clearly being used for handoff. This commit will suppresses the banner then.
## PR Checklist
* [x] Closes#13314
* [x] I work here
## Validation Steps Performed
* Modify `TerminalPage::ShowSetAsDefaultInfoBar` to not check for
`CascadiaSettings::IsDefaultTerminalSet()`
* Set Terminal Dev as the default
* Set incoming connections to open in the latest Terminal window
* Delete `state.json` after every test below
* Launching Terminal Dev shows the banner ✅
Launching `cmd.exe` dismisses the banner in the current Terminal ✅
* Launching `cmd.exe` launches Terminal Dev without banner ✅
These files are vestigial, because we are also shipping (either as loose
files or embedded in resources.pri) precompiled xbf/xaml binary format
files.
This saves us almost 500kb on disk.
Fixes#11687
Validation
----------
I ran a local build and saw that it produced a working Terminal, packaged
and unpackaged.
## Summary of the Pull Request
This introduces a selection marker overlay that tells the user which endpoint is currently being moved by the keyboard. The selection markers are respect font size changes and `cursor` color.
## References
#715 - Keyboard Selection
#2840 - Keyboard Selection Spec
#5804 - Mark Mode Spec
## Detailed Description of the Pull Request / Additional comments
- `TermControl` layer:
- Use a canvas (similar to the one used for hyperlinks) to be able to draw the selection markers.
- If we are notified that the selection changed, update the selection markers appropriately.
- `UpdateSelectionMarkersEventArgs` lets us distinguish between mouse and keyboard selections. `ClearMarkers` is set to true in the following cases...
1. Mouse selection, via SetEndSelectionPoint
2. `LeftClickOnTerminal`, pretty self-explanatory
3. a selection created from searching for text
- `ControlCore` layer:
- Responsible for notifying `TermControl` to update the selection markers when a selection has changed.
- Transfers info (the selection endpoint positions and which endpoint we're moving) from the terminal core to the term control.
- `TerminalCore` layer:
- Provides the viewport position of the selection endpoints.
## Validation Steps Performed
- mouse selection (w/ and w/out shift) --> no markers
- keyboard selection --> markers
- markers update appropriately when we pivot the selection
- markers scroll when you hit a boundary
- markers take the color of the cursor color setting
- markers are resized when the font size changes
## Summary of the Pull Request
When you execute a `cls` in the cmd shell, or `Clear-Host` in
PowerShell, we have a pair of shims that attempt to detect those
operations and forward an `ED3` sequence to conpty to clear the
scrollback.
If there was a linefeed at the bottom of the viewport immediately
prior to those functions being called, that event might still be
pending, and only forwarded to conpty after the `ED3`. The result
then is a line pushed into the scrollback that shouldn't be there.
This PR tries to avoid that situation by forcing the renderer to
flush before the `ED3` sequence is sent.
## References
The `cls` and `Clear-Host` shims were originally added in PR #5627.
## PR Checklist
* [x] Closes#5770
* [x] Closes#13320
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
I've manually tested in PowerShell with `echo Hello; Clear-Host` (this
is the only way I could reliably reproduce the original problem), and in
the cmd shell with `cls`. Both cases are now working as expected.
When we send this ShowWindow message, if we send it to it's
going to need to get processed by the window message thread before
returning. We're handling this message under lock. However, the first
thing the conhost message thread does is lock the console. That'll
deadlock us. So unlock here, first, to let the message thread deal with
this message, then re-lock so later on this thread can unlock again
safely.
* [x] Closes#13301
* [x] Tested conhost
* [x] Tested terminal
When I moved this into ControlCore, I forgot that UserScrollViewport is usually triggered by the scrollbar updating, so it doesn't ask the UI to update. Since this logic is in ControlCore, it's sorta in a weird place where it needs to communicate both up and down:
* update the `Terminal`'s viewport position
* update the `TermControl`'s scrollbar position
Checklist:
* [x] Closes a bug bash bug
* [x] Missed in #12948
* See also #11000
ed27737 contains a regression were a `RECT` in `GdiEngine` wasn't properly
initialized anymore. Due to this, rendering during scrolling behaved erratic.
To find other cases of this bug in ed27737 the following regex was used:
```
^-.* = \{\s*\d*\s*\};
```
It appears that only `GdiEngine` was affected by a bug of this kind,
but just to be sure, this PR reverts all other instances.
This bug was likely caused when I tried to undo some of the changes in
ed27737 to make the PR smaller, but failed to revert the code properly.
## PR Checklist
* [x] Closes#13270
* [x] I work here
## Validation Steps Performed
I'm unable to reproduce the issue on my hardware and am unable to test
this change, but the uninitialized struct is clearly a bug regardless.
Co-authored-by: James Holderness <j4_james@hotmail.com>
Adds an accelerator key for the shell extension: `T` for stable, `P` for preview and `D` for dev.
# Validation
Ran a dev build and saw the keyboard accelerator assigned.
Closes#13061
## Summary of the Pull Request
Up to now we haven't supported passing `DCS` sequences over conpty, so
any `DCS` operations would just be ignored in Windows Terminal. This PR
introduces a mechanism whereby we can selectively pass through
operations that could reasonably be handled by the connected terminal
without interfering with the regular conpty renderer. For now this is
just used to support restoring the `DECCTR` color table report.
## References
Support for `DECCTR` was originally added to conhost in PR #13139.
## PR Checklist
* [x] Closes#13223
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
The way this works is we have a helper method in `AdaptDispatch` that
`DCS` operations can use to create a passthrough `StringHandler` for the
incoming data instead of their usual handler. To make this passthrough
process more efficient, the handler buffers the data before forwarding
it to conpty.
However, it's important that we aren't holding back data if output is
paused before the string terminator, so we need to flush the buffer
whenever we reach the end of the current write operation. This is
achieved by querying a new method in the `StateMachine` that lets us
know if we're currently dealing with the last character.
Another issue that came up was with the way the `StateMachine` caches
sequences that it might later need to forward to conpty. In the case of
string sequences like `DCS`, we don't want the actual string data cached
here, because that will just waste memory, and can also result in the
data being mistakenly output. So I've now disabled that caching when
we're in any of the string processing states.
## Validation Steps Performed
I've manually confirmed that the `DECCTR` sequence can now update the
color table in Windows Terminal. I've also added a new unit test in
`ConptyRoundtripTests` to verify the sequence is being passed through
successfully.
As described in #13238. libuv sends a focus event to jiggle the handle. Now that we support focus events as VT input (#12900), we'd translate those focus events to VT input as well. That combination of things caused exiting neovim to emit a `\x1b[O` to the input line of the shell when exited.
To fix this, we're going to secretly filter out any focus events that came from the API, before translating to VT. We're fortunate here, the `FOCUS_EVENT_RECORD` version of the ctor is only called by the API.
* [x] Closes#13238
When loading color schemes from Json, check if GetValueForKey failed. If
it did, and we were searching for the colors "purple"/"brightPurple",
swap out the color name with "magenta"/"brightMagenta" and try again.
This was tested manually by creating a new color scheme using the colors
"magenta"/"brightMagenta" and loading it, then printing colored text in
the terminal to assure that the colors were correctly assigned as
purple.
This changes the color loader to use an index pair table to add support
for alternate color names.
## Validation Steps Performed
- Manually edit settings.json, creating a new color scheme with colors
"magenta" and "brightMagenta"
- View the color scheme in settings - the colors will appear as "purple"
and "brightPurple" in the UI
- Run a program that prints colored text, purple and brightPurple text
will appear in the colors defined as magenta and brightMagenta
- Modify the color scheme in the settings UI and save it, the colors
will be saved as "purple" and "brightPurple" *(I think this is the
right behavior, since calling them "magenta" is technically a
mistake)*
- Repeat the steps above with a normal color scheme - colors named
"purple" and "brightPurple" still load properly
Closes#11456
Windows Terminal Preview gets existing settings from Release build if
Preview settings are empty
This ensures that when settings are empty or not existent, we check if
we're currently in a preview build and if we are, we attempt to grab
settings from the Release build's setting path instead. We tested it
manually by changing settings in Release build and confirming that
changes migrated to Preview when settings are empty or not existent.
Additionally, we tested that settings.json of the running build changed.
We also ran existing TAEF testing locally and it passed.
In LoadAll() function in
src\cascadia\TerminalSettingsModel\CascadiaSettingsSerialization.cpp, we
first checked if the settings file us empty/exists via settingsString.
If it does not and we are in the Preview build, we try loading the
Release build's settings. We created modified versions of
CascadiaSettings::_settingsPath() and GetBaseSettingsPath() to get the
path for the Release build's settings. If the Release build settings do
exist and firstTimeSetup is true, we set it to settingsString so it can
be written to disk via WriteSettingsToDisk(). Note that currently we
hardcode the path of the Release build. This pull request was worked on
with @Dannihu01.
## Validation Steps Performed Test1: Setting to firstTimeSetup is true
and loading settings.json from WT release when release exists -> Result:
settings.json AND GUI reflected WT release’s settings
Test2: Setting to firstTimeSetup is true and loading settings.json from
WT release when release doesn’t exist -> Result: settings.json AND GUI
reflected DEFAULT settings
Test3: (After running Test1) Setting to firstTimeSetup is false and
seeing if current settings.json matches WT release. (See if it doesn’t
change) -> Result: settings.json AND GUI reflected WT release’s settings
Closes#6855
Co-authored-by: Danniell Hu <dannihu@umich.edu>
## Summary of the Pull Request
This fixes the crashes caused by using a screen reader when in an app that uses the alt buffer via two changes:
1. Fix `Terminal::ViewEndIndex()`
- `UiaTextRangeBase` receives a coordinate that is outside of the bounds of the text buffer via the following chain of functions... `_getDocumentEnd()` --> `GetLastNonSpaceCharacter()` --> `_getOptimizedBufferSize()` --> `GetTextBufferEndPoisition()` --> `ViewEndIndex()`
- Since support for the alt buffer was added recently, `ViewEndIndex()` was recently changed, so that explains why this issue came up recently. We were accidentally setting the view end index to `height` instead of `height-1`. Thanks @j4james for finding this!
- The UIA code would get the "exclusive end" of the alt buffer. Since it was using `ViewEndIndex()` to calculate that, it was one more than it should be. The UIA code has explicit allowance for "one past the end of the viewport" in its `IsInBounds()` check. Since the `ViewEndIndex()` is way beyond that, it's not allowed, hitting the fail fast.
2. Replace `FAIL_FAST_IF` with `assert`
- These fail fast calls have caused so many issues with our UIA code. Those checks still provide value, but they shouldn't take the whole app down. This change replaces the `Viewport` and `UiaTextRangeBase` fail fasts with asserts to still perform those checks, but not take down the entire app in release builds.
Closes#13183
## Validation Steps Performed
While using Narrator...
- opened nano in bash
- generated text and scrolled in nano
- generated text and scrolled in PowerShell
See also: #12799, the origin of much of this.
This change evolved over multiple phases.
### Part the first
When we create a defterm connection in `TerminalPage::_OnNewConnection`,
we don't have the hosting HWND yet, so the tab gets created without one.
We'll later get called with the owner, in `Initialize`.
To remedy this, we need to:
* In `Initialize`, make sure to update any existing controls with the
new owner.
* In `ControlCore`, actually propogate the new owner down to the
connection
### Part the second
DefTerm launches don't actually request focus mode, so the Terminal
never sends them focus events. We need those focus events so that the
console can request foreground rights.
To remedy this, we need to:
* pass `--win32input` to the commandline used to initialize OpenConsole
in ConPTY mode. We request focus events at the same time we request
win32-input-mode.
* I also added `--resizeQuirk`, because _by all accounts that should be
there_. Resizing in defterm windows should be _wacky_ without it, and
I'm a little surprised we haven't seen any bugs due to this yet.
### Part the third
`ConsoleSetForeground` expects a `HANDLE` to the process we want to give
foreground rights to. The problem is, the wire format we used _also_
decided that a HANDLE value was a good idea. It's not. If we pass the
literal value of the HANDLE to the process from OpenConsole to conhost,
so conhost can call that API, the value that conhost uses there will
most likely be an invalid handle. The HANDLE's value is its value in
_OpenConsole_, not in conhost.
To remedy this, we need to:
* Just not forward `ConsoleSetForeground`. Turns out, we _can_ just call
that in OpenConsole safely. There's no validation. So just instantiate
a static version of the Win32 version of ConsoleControl, just to use
for SetForeground. (thanks Dustin)
* [x] Tested manually - Win+R `powershell`, `notepad` spawns on top.
Closes#13211
Implements the **FTCS_PROMPT** sequence, `OSC 133 ; A ST`. In this PR, it's just used to set a simple Prompt mark on the current line, in the same way that the iTerm2 sequence works.
There's rumination in #11000 on how to implement the rest of the FTCS sequences.
This is broken into its own PR at the moment. [Quoth j4james](https://github.com/microsoft/terminal/pull/12948#issuecomment-1136360132):
> That should be just as easy, and I've noticed a couple of other terminals that are doing that, so it's not unprecedented. If we don't have any immediate use for the other options, there shouldn't be any harm in ignoring them initially.
>
> And the benefit of going with the more widely supported sequence is that we're more likely to benefit from any shells that have this functionality built in. Otherwise they're forced to try and detect the terminal, which is practically impossible for Windows Terminal. Even iTerm2 supports the `OSC 133` sequence, so we'd probably be the only odd one out.
This part of the plumbing is super easy, so I thought it would be valuable to add regardless if we get to the whole of FTCS in 1.15.
* [x] I work here
* [x] Tested manually - in my pwsh `$PROFILE`:
```pwsh
function prompt {
$loc = $($executionContext.SessionState.Path.CurrentLocation);
$out = "PS $loc$('>' * ($nestedPromptLevel + 1)) ";
$out += "$([char]27)]9;9;`"$loc`"$([char]07)";
$out += "$([char]27)]133;A;$([char]7)"; # add the FTCS_PROMPT to the... well, end, but you get the point
return $out
}
```
* See also #11000
* conhost requires an additional dependency in Windows, which might
cause us trouble in WPG
* Terminal requires an additional *package* dependency, which *will*
cause us trouble in WPG (since GmDls is about 3MB)
I chose to scope the feature checks to MidiOut directly, as I wanted to
keep the delay behavior in MidiAudio::PlayNote. This is negotiable.
References #13252
Adds support for marks in the scrollbar. These marks can be added in 3
ways:
* Via the iterm2 `OSC 1337 ; SetMark` sequence
* Via the `addMark` action
* Automatically when the `experimental.autoMarkPrompts` per-profile
setting is enabled.
#11000 has more tracking for the big-picture for this feature, as well
as additional follow-ups. This set of functionality seemed complete
enough to send a review for now. That issue describes these how I wish
these actions to look in the fullness of time. This is simply the v0.1
from the hackathon last month.
#### Actions
* `addMark`: add a mark to the buffer. If there's a selection, use
place the mark covering at the selection. Otherwise, place the mark
on the cursor row.
- `color`: a color for the scrollbar mark. This is optional - defaults
to the `foreground` color of the current scheme if omitted.
* `scrollToMark`
- `direction`: `["first", "previous", "next", "last"]`
* `clearMark`: Clears marks at the current postition (either the
selection if there is one, or the cursor position.
* `clearAllMarks`: Don't think this needs explanation.
#### Per-profile settings
* `experimental.autoMarkPrompts`: `bool`, default `false`.
* `experimental.showMarksOnScrollbar`: `bool`
## PR Checklist
* [x] Closes#1527
* [x] Closes#6232
## Detailed Description of the Pull Request / Additional comments
This is basically hackathon code. It's experimental! That's okay! We'll
figure the rest of the design in post.
Theoretically, I should make these actions `experimental.` as well, but
it seemed like since the only way to see these guys was via the
`experimental.showMarksOnScrollbar` setting, you've already broken
yourself into experimental jail, and you know what you're doing.
Things that won't work as expected:
* resizing, ESPECIALLY reflowing
* Clearing the buffer with ED sequences / Clear Buffer
I could theoretically add velocity around this in the `TermControl`
layer. Always prevent marks from being visible, ignore all the actions.
Marks could still be set by VT and automark, but they'd be useless.
Next up priorities:
* Making this work with the FinalTerm sequences
* properly speccing
* adding support for `showMarksOnScrollbar: flags(categories)`, so you
can only display errors on the scrollbar
* adding the `category` flag to the `addMark` action
## Validation Steps Performed
I like using it quite a bit. The marks can get noisy if you have them
emitted on every prompt and the buffer has 9000 lines. But that's the
beautiful thing, the actions work even if the marks aren't visible, so
you can still scroll between prompts.
<details>
<summary>Settings blob</summary>
```jsonc
// actions
{ "keys": "ctrl+up", "command": { "action": "scrollToMark", "direction": "previous" }, "name": "Previous mark" },
{ "keys": "ctrl+down", "command": { "action": "scrollToMark", "direction": "next" }, "name": "Next mark" },
{ "keys": "ctrl+pgup", "command": { "action": "scrollToMark", "direction": "first" }, "name": "First mark" },
{ "keys": "ctrl+pgdn", "command": { "action": "scrollToMark", "direction": "last" }, "name": "Last mark" },
{ "command": { "action": "addMark" } },
{ "command": { "action": "addMark", "color": "#ff00ff" } },
{ "command": { "action": "addMark", "color": "#0000ff" } },
{ "command": { "action": "clearAllMarks" } },
// profiles.defaults
"experimental.autoMarkPrompts": true,
"experimental.showMarksOnScrollbar": true,
```
</details>
ed27737 contains a regression where (pseudocode)
```c
unsigned long ulActualDelta;
short ScreenInfo.WheelDelta;
delta *= (ScreenInfo.WheelDelta / (short)ulActualDelta);
// ^^^^^^^
```
was changed to
```c
delta *= (ScreenInfo.WheelDelta / ulActualDelta);
```
Due to `ulActualDelta` being unsigned, the new code casts the signed integer
to a unsigned one first, before doing the division. This causes scrolling
downwards (`WheelDelta` is negative) to appear as a large positive `delta`.
## PR Checklist
* [x] Closes#13253
* [x] I work here
## Validation Steps Performed
* Scrolling up/down works in OpenConsole again ✅
When #13160 introduced a new interface to the IConsoleHandoff idl, it
changed midl's RPC proxy stub lookup algorithm from a direct GUID
comparison to an unrolled binary search. Now, that would ordinarily not
be a problem...
However, in #11610, we took a shortcut and replaced `memcmp` -- used
only by RPC for GUID comparison -- with a direct GUID-only equality
comparator. This worked totally fine, and ordinarily would not be a
problem...
The unrolled binary search unfortunately _relies on memcmp's contract_:
it uses memcmp to match against a fully sorted set. Our memcmp only
returned 0 or 1 (equal or not), and it knew nothing about ordering.
When a package that contains a PackagedCOM proxy stub is installed, it
is selected as the primary proxy stub for any interfaces it can proxy.
After all, interfaces are immutable, so it doesn't matter whose proxy
you're using. Now, given that we installed a *broken* proxy... *all*
IIDs that got whacked by our memcmp issue broke for every consumer.
To fix it: instead of implementing memcmp ourselves, we're just going to
take a page out of WinAppSDK's book and link this binary using the
"Hybrid CRT" model. It will statically link any parts of the STL it uses
(none) and dynamically link the ucrt (which is guaranteed to be present
on Windows.)
Sure, the binary size goes up from 8k to 24k, but... the cost is never
having to worry about this again.
Closes#13251
## Summary of the Pull Request
When a profile gets deleted, we were navigating to the next item assuming it was a profile when it may not be. This commit fixes this by checking the tag of the next menu item before we navigate to it.
## PR Checklist
* [x] Closes#13125
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Deleting the last profile in the SUI doesn't cause a crash
If we want to make Windows Terminal the default terminal under Windows,
we'll have to make conhost "handoff" incoming connections by default.
But this poses a problem: How can the seldomly updated conhost know
whether the routinely updated Windows Terminal version is actually willing
to accept such handoffs by default (it might be unwilling due to bugs, etc.)?
This commit solves the issue by introducing:
* A marker interface (`IDefaultTerminalMarker`): If it exists,
Windows Terminal indicates its willingness to accept the handoff.
* Turning the all-0 GUID from being synonymous for conhost,
to being synonymous for "Let Windows decide". Without this we wouldn't
be able to differentiate between users who consciously chose conhost
as their default terminal, vs. users who want the standard behavior.
Testing fallback behavior:
* Install "Terminal" 1.13
* Delete the 2 keys below `HKCU\Console\%%Startup`
* Enable `Feature_AttemptHandoff` in `features.xml`
Return `true` from `DefaultApp::CheckShouldTerminalBeDefault`
* Replace `conhost.exe` and `console.dll` with `sfpcopy` after building
* Launching `cmd.exe` launches as a conhost window ✅
(because "Terminal" 1.13 lacks the marker interface)
* Open properties page in `conhost.exe`
"Let Windows decide" is select by default ✅
* Changing the selection writes the new value ✅
Testing the new behavior:
* Delete the 2 keys below `HKCU\Console\%%Startup`
* Enable `Feature_AttemptHandoff` in `features.xml`
Return `true` from `DefaultApp::CheckShouldTerminalBeDefault`
* Use `CLSID_WindowsTerminalConsoleDev` and `CLSID_WindowsTerminalTerminalDev`
for the initialization of `TerminalDelegationPair`
* Replace `conhost.exe` and `console.dll` with `sfpcopy` after building
* Deploy the "Terminal Dev" package
* Launching `cmd.exe` launches "Terminal Dev" ✅
(because "Terminal Dev" has the marker interface)
* Open the settings tab
"Let Windows decide" is select by default ✅
* Changing the selection and saving writes the new value ✅
(cherry picked from commit 1b81c6540f)
Service-Card-Id: 82925080
Service-Version: Inbox
If we want to make Windows Terminal the default terminal under Windows,
we'll have to make conhost "handoff" incoming connections by default.
But this poses a problem: How can the seldomly updated conhost know
whether the routinely updated Windows Terminal version is actually willing
to accept such handoffs by default (it might be unwilling due to bugs, etc.)?
This commit solves the issue by introducing:
* A marker interface (`IDefaultTerminalMarker`): If it exists,
Windows Terminal indicates its willingness to accept the handoff.
* Turning the all-0 GUID from being synonymous for conhost,
to being synonymous for "Let Windows decide". Without this we wouldn't
be able to differentiate between users who consciously chose conhost
as their default terminal, vs. users who want the standard behavior.
## Validation Steps Performed
Testing fallback behavior:
* Install "Terminal" 1.13
* Delete the 2 keys below `HKCU\Console\%%Startup`
* Enable `Feature_AttemptHandoff` in `features.xml`
Return `true` from `DefaultApp::CheckShouldTerminalBeDefault`
* Replace `conhost.exe` and `console.dll` with `sfpcopy` after building
* Launching `cmd.exe` launches as a conhost window ✅
(because "Terminal" 1.13 lacks the marker interface)
* Open properties page in `conhost.exe`
"Let Windows decide" is select by default ✅
* Changing the selection writes the new value ✅
Testing the new behavior:
* Delete the 2 keys below `HKCU\Console\%%Startup`
* Enable `Feature_AttemptHandoff` in `features.xml`
Return `true` from `DefaultApp::CheckShouldTerminalBeDefault`
* Use `CLSID_WindowsTerminalConsoleDev` and `CLSID_WindowsTerminalTerminalDev`
for the initialization of `TerminalDelegationPair`
* Replace `conhost.exe` and `console.dll` with `sfpcopy` after building
* Deploy the "Terminal Dev" package
* Launching `cmd.exe` launches "Terminal Dev" ✅
(because "Terminal Dev" has the marker interface)
* Open the settings tab
"Let Windows decide" is select by default ✅
* Changing the selection and saving writes the new value ✅
## Summary of the Pull Request
This introduced the `toggleBlockSelection` action to allow users to create a block selection using only the keyboard. This is not bound to any keys by default, however it is added to the command palette.
## References
#4993 - Epic
#5804 - Spec
## Validation Steps Performed
- [X] Mark mode always starts in line selection mode
- [X] Mouse selections are always in line selection mode by default
- [X] Can toggle block selection for an existing selection (regardless of how it was created)
- [X] The selection is copied properly (aka, no rendering issues)
Previously this project used a great variety of types to present text buffer
coordinates: `short`, `unsigned short`, `int`, `unsigned int`, `size_t`,
`ptrdiff_t`, `COORD`/`SMALL_RECT` (aka `short`), and more.
This massive commit migrates almost all use of those types over to the
centralized types `til::point`/`size`/`rect`/`inclusive_rect` and their
underlying type `til::CoordType` (aka `int32_t`).
Due to the size of the changeset and statistics I expect it to contain bugs.
The biggest risk I see is that some code potentially, maybe implicitly, expected
arithmetic to be mod 2^16 and that this code now allows it to be mod 2^32.
Any narrowing into `short` later on would then throw exceptions.
## PR Checklist
* [x] Closes#4015
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
Casual usage of OpenConsole and Windows Terminal. ✅
This PR introduces the framework for the `DECRSTS` sequence which is
used to restore terminal state reports. But to start with, I've just
implemented the `DECCTR` color table report, which provides a way for
applications to alter the terminal's color scheme.
## PR Checklist
* [x] Closes#13132
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
I've added the functions for parsing DEC RGB and HLS color formats into
the `Utils` class, where we've got all our other color parsing routines,
since this functionality will eventually be needed in other VT protocols
like Sixel and ReGIS.
Since `DECRSTS` is a `DCS` sequence, this only works in conhost for now,
or when using the experimental passthrough mode in Windows Terminal.
## Validation Steps Performed
I've added a number of unit tests to check that the `DECCTR` report is
being interpreted as expected. This includes various edge cases (e.g.
omitted and out-of-range parameters), which I have confirmed to match
the color parsing on a real VT240 terminal.
## Summary of the Pull Request
The `DECPS` (Play Sound) escape sequence provides applications with a
way to play a basic sequence of musical notes. This emulates
functionality that was originally supported on the DEC VT520 and VT525
hardware terminals.
## PR Checklist
* [x] Closes#8687
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number
where discussion took place: #8687
## Detailed Description of the Pull Request / Additional comments
When a `DECPS` control is executed, any further output is blocked until
all the notes have finished playing. So to prevent the UI from hanging
during this period, we have to temporarily release the console/terminal
lock, and then reacquire it before returning.
The problem we then have is how to deal with the terminal being closed
during that unlocked interval. The way I've dealt with that is with a
promise that is set to indicate a shutdown. This immediately aborts any
sound that is in progress, but also signals the thread that it needs to
exit as soon as possible.
The thread exit is achieved by throwing a custom exception which is
recognised by the state machine and rethrown instead of being logged.
This gets it all the way up to the root of the write operation, so it
won't attempt to process anything further output that might still be
buffered.
## Validation Steps Performed
Thanks to the testing done by @jerch on a real VT525 terminal, we have a
good idea of how this sequence is supposed to work, and I'm fairly
confident that our implementation is reasonably compatible.
The only significant difference I'm aware of is that we support multiple
notes in a sequence. That was a feature that was documented in the
VT520/VT525 manual, but didn't appear to be supported on the actual
device.
MSFT-33471786 is one of the most common crashes we have right now.
Memory dumps suggest that `VtEngine::UpdateViewport` is called with a rectangle
like `(0, 46, 119, 29)` (left, top, right, bottom), which is a rectangle of
negative height. When the `_invalidMap` is resized the negative size gets
turned into a very large unsigned integer, which results in an OOM exception,
crashing OpenConsole.
`VtEngine::UpdateViewport` is called by `Renderer::_CheckViewportAndScroll`
which holds a (cached) old and a new viewport. The old viewport was
`(0, 46, 119, 75)` which is exceedingly similar to the invalid, new viewport.
It's bottom coordinate is also coincidentally larger by exactly 46 (top).
The viewport comes from the `SCREEN_INFORMATION` class whose `SetViewport`
function was highly suspicious as it has a branch which updates the bottom
to be the buffer height, but leaves the top unmodified.
`SCREEN_INFORMATION::SetViewport` is called by `SetConsoleWindowInfo` which
processes user-provided data. A repro of the crash can be constructed with:
```
SMALL_RECT rect{0, 46, 119, 75};
SetConsoleWindowInfo(GetStdHandle(STD_OUTPUT_HANDLE), TRUE, &rect);
```
Closes#13193
Closes MSFT-33471786
## Validation Steps Performed
Ensured the following code doesn't crash when run under Windows Terminal:
```
SMALL_RECT rect{0, 46, 119, 75};
SetConsoleWindowInfo(GetStdHandle(STD_OUTPUT_HANDLE), TRUE, &rect);
```
This commit hides the "Open in Terminal" context menu option when the
context menu is opened in a non-filesystem path like "Quick Actions".
Closes#12578
This is a big hammer to put out this fire. We're keeping the hiding around for now, cause we think that's likely the one that the internal tests use that we really care about here. If we need to bring this back, we can.
* [x] Closes#13158
* [x] Closes#13162
* [x] Validated these both manually
* [x] `[Native]::ShowWindow([Native]::GetConsoleWindow(), 6)` still works
Prevents a null pointer dereference when attempting to split a settings tab, due to it not being a terminal tab.
* [x] Closes#13166
## Validation Steps Performed
Manually tested.
This only impacts the UI. We can take a workitem to rename the loc data
later. When the user specifies zh-Hans/zh-Hant, the resource mapper does
the right thing.
Related to #8984
Use a throttled update to update our window state. Throttling should prevent scenarios where the Terminal window state and PTY window state get de-sync'd, and cause the window to minimize/restore constantly in a loop. "Should" is doing a lot of work in this sentence.
A 200ms delay was chosen because it's the typical animation timeout in Windows. This does result in a delay between the PTY requesting a change to the window state and the Terminal realizing it, but should mitigate issues where the Terminal and PTY get desync'd.
I think we're overall not super confident that this fixes the root causes of the issue. Rather, we're hopeful that a small amount of throttling here should leave time for the Terminal and pty to sync back up. We're comfortable enough with that as a bandaid for 1.14 preview, to see how this behaves in the wild.
ThemeResources are a persistent pain.
Regressed in #13083. See also #12775 et. al.
We can't just put those here though as StaticResources, because XAML will evaluate their values when the App is first loaded, and we'll always use the value from the OS theme, regarless of the requested theme. Kinda the same thing we've had to do with TabViewBackground in the past.
* [x] Fixes something we noticed right before shipping
We're doing it this way because ThemeResources are tricky. We
default in XAML to using the appropriate ThemeResource background
color for our TabRow. When tabs in the titlebar are _disabled_,
this will ensure that the tab row has the correct theme-dependent
value. When tabs in the titlebar are _enabled_ (the default),
we'll switch the BG to Transparent, to let the Titlebar Control's
background be used as the BG for the tab row.
We can't do it the other way around (default to Transparent, only
switch to a color when disabling tabs in the titlebar), because
looking up the correct ThemeResource from and App dictionary is a
capital-H Hard problem.
* [x] Closes#13143
* [x] I work here
* [x] validated manually:
- [x] showTabsInTitlebar: false, true
- [x] useAcrylicInTabRow: false, true
- [x] theme: light, dark
* [x] Need to check if this is regressed the same in 1.13. I suspect it is.
## Summary of the Pull Request
Introduces a non-configurable version of mark mode to Windows Terminal. It has the following interactions defined:
- <kbd>ctrl+shift+m</kbd> --> Enter Mark Mode
- when in Mark Mode...
- <kbd>ESC</kbd> --> Exit Mark Mode
- arrow keys --> move "start"
- <kbd>shift</kbd> + arrow keys --> anchor "start", move "end"
- <kbd>ctrl+a</kbd> --> select all
- when a selection is active...
When in mark mode, the cursor does not blink.
## References
#4993 - [Epic] Keyboard Selection
## PR Checklist
* [X] Closes#715
* [X] Provides a resolution for #11985
## Detailed Description of the Pull Request / Additional comments
- `TermControl`:
- `TermControl.cpp` just adds logic to prevent the cursor from blinking when in mark mode
- `ControlCore`
- in the same place we handle quick edit, we add an entry point to mark mode
- `TerminalCore`
- this leverages `UpdateSelection()` and other quick edit functions to make mark mode happen
## Validation Steps Performed
- [x] Make selection, split pane, close pane
- NOTE: A similar scenario caused a crash at one point. Really weird. Keep an eye on it.
- [x] Cursor is off when in mark mode
- [x] general movement/selection
- [x] general movement/selection that forces the viewport to move
- [x] In mark mode, selectAll...
- [x] arrow keys --> move start
- [x] shift + arrow keys --> move end
- [x] (regardless of mark mode) if selection active, enter --> copy to clipboard
Well this one feels dumb.
Make sure to also initially set the visibility of ConPTY windows created for DefTerm connections.
* [x] Closes#13066 for real.
* [x] tested manually.
A bad merge, that actually revealed a horrible bug.
There was a secret conflict between the code in #12526 and #12515. 69b77ca was a bad merge that hid just how bad the issue was. Fixing the one line `nullptr`->`this` in `InteractivityFactory` resulted in a window that would flash uncontrollably, as it minimized and restored itself in a loop. Great.
This can seemingly be fixed by making sure that the conpty window is initially created with the owner already set, rather than relying on a `SetParent` call in post. This does pose some complications for the #1256 future we're approaching. However, this is a blocking bug _now_, and we can figure out the tearout/`SetParent` thing in post.
* fixes#13066.
* Tested with the script in that issue.
* Window doesn't flash uncontrollably.
* `gci | ogv` still works right
* I work here.
* Opening a new tab doesn't spontaneously cause the window to minimize
* Restoring from minimized doesn't yeet focus to an invisible window
* Opening a new tab doesn't yeet focus to an invisible window
* There _is_ a viable way to call `GetAncestor` s.t. it returns the Terminal's hwnd in Terminal, and the console's in Conhost
The `SW_SHOWNOACTIVATE` change is also quite load bearing. With just `SW_NORMAL`, the pseudo window (which is invisible!) gets activated whenever the terminal window is restored from minimized. That's BAD.
There's actually more to this as well.
Calling `SetParent` on a window that is `WS_VISIBLE` will cause the OS to hide the window, make it a _child_ window, then call `SW_SHOW` on the window to re-show it. `SW_SHOW`, however, will cause the OS to also set that window as the _foreground_ window, which would result in the pty's hwnd stealing the foreground away from the owning terminal window. That's bad.
`SetWindowLongPtr` seems to do the job of changing who the window owner is, without all the other side effects of reparenting the window.
Without `SetParent`, however, the pty HWND is no longer a descendant of the Terminal HWND, so that means `GA_ROOT` can no longer be used to find the owner's hwnd. For even more insanity, without `WS_POPUP`, none of the values of `GetAncestor` will actually get the terminal HWND. So, now we also need `WS_POPUP` on the pty hwnd. To get at the Terminal hwnd, you'll need
```c++
GetAncestor(GetConsoleWindow(), GA_ROOTOWNER)
```
This PR adds support for the VT line rendition attributes in the DirectX
renderer, which allows for double-width and double-height line
renditions.
Line renditions were first implemented in conhost (with the GDI
renderer) in PR #8664. Supporting them in the DX renderer now is a
small step towards #11595.
The DX implementation is very similar to the GDI one. When a particular
line rendition is requested, we create a transform that is applied to
the render target. And in the case of double-height renditions, we also
initialize some clipping offsets to allow for the fact that we only
render half of a line at a time.
One additional complication exists when drawing the cursor, which
requires a two part process where it first renders to a command list,
and then draw the command list in a second step. We need to temporarily
reset the transform in that first stage otherwise it ends up being
applied twice.
I've manually tested the renderer in conhost by setting the `UseDx`
registry entry and confirmed that it passes the _Vttest_ double-size
tests as well as several of my own tests. I've also checked that the
renderer can now handle horizontal scrolling, which is a feature we get
for free with the transforms.
## Summary of the Pull Request
When the conpty passthrough mode is enabled, it often needs to send `DSR-CPR` queries (cursor position reports) to the client terminal to obtain the current cursor position. However, the code that originally handled the responses to these queries got broken by the refactoring of the `ConGetSet` API. This PR is an attempt to correct that regression.
## References
The conpty passthrough mode was introduced in PR #11264.
The refactoring that broke the cursor position handling was in PR #12703.
## PR Checklist
* [x] Closes#13106
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
Prior to the `ConGetSet` refactoring, the code that handled `DSR-CPR` responses (`InteractDispatch::MoveCursor`) would pass the cursor position to `ConGetSet::SetCursorPosition`, which in turn would forward it to the `SetConsoleCursorPositionImpl` API, and from there to the `VtIo` class.
After the refactor, all of those intermediate steps were removed - the cursor was simply updated directly in `InteractDispatch::MoveCursor`, and the `VtIo` call was moved from `SetConsoleCursorPositionImpl` to `InteractDispatch` (since that was the only place it was actually required).
However, when the conpty passthrough mode was introduced - which happened in parallel - it relied on the `SetConsoleCursorPositionImpl` API being called from `InteractDispatch` in order to handle its own `DSR-CPR` responses, and that's why things stopped working when the two PRs merged.
So what I've done now is made `InteractDispatch::MoveCursor` method call `SetConsoleCursorPositionImpl` again (although without the intermediate `ConGetSet` overhead), and moved the `VtIo::SetCursorPosition` call back into `SetConsoleCursorPositionImpl`.
This is not ideal, and there are still a bunch of problems with the `DSR-CPR` handling in passthrough mode, but it's at least as good as it was before.
## Validation Steps Performed
I've just manually tested various shells with passthrough mode enabled, and confirmed that they're working better now. There are still issues, but nothing that wasn't already a problem in the initial implementation, at least as far as I can tell.
This regressed in ad2358d.
We're interested in the size of the viewport only, but it can shift up/down
during scrolling. In these situations we shouldn't resize our buffers of course.
## Validation Steps Performed
* Scroll
* Not setting `ApiInvalidations::Size` ✅
## Summary of the Pull Request
Add `Find` to tab context menu as describe in issue #5633.
## PR Checklist
* [x] Closes#5633
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Detailed Description of the Pull Request / Additional comments
Just wanted to solve `Easy Starter` issue, so any corrections/suggestions welcome. There's a couple of points I'm not sure of
* Placement of item within menu, currently it's at the end before close tab block.
* Should it be named longer, something like `Find in Tab` of just `Find` is fine?
* The workaround for focus similar to tab rename is a bit annoying, especially because it required adding a method to `TermControl` but without it find window obviously opens without focus which is bad.
## Validation Steps Performed
Open menu, press menu item try to find things via opened find dialog.
This commit includes various minor improvements to til::hash/point/size/rect
which accumulated while working on #4015.
* Allow xvalue containers and non-`size_t` indices in `til::at`.
* `til::as_unsigned` can be used to reinterpret a potentially signed integer
as a unsigned one. This can potentially enable some optimizations as no sign
extension is needed anymore. `til::hash` can make use of this to drop about
20% of the hashing of signed integers <= 32 bit. On x86 this translates to
a `mov` (virtually no latency) or no instructions at all, instead of
requiring a `movsx` (some latency) for sign extension.
* `til::point` operators that prefer mutability.
This is a opinionated change, but it follows the STL style beter and
generates less assembly.
* Simpler `rect` scale_up/down and `size` divide_ceil.
`scale_up` will not depend on the operator header anymore.
`scale_down` / `divide_ceil` can be implemented without checked numerics,
so I did. It also follows the related GdiEngine code better now, which
makes me confident that we can replace GdiEngine's code with this.
* Removal of rect-size-shift operators.
They were only used in DxEngine and confusing as they weren't commutative.
Adding and then subtracting a size from a rect (and vice versa) didn't do
what you'd intuitively think it'd do. The code was replaced with addition
and clamps in DxEngine.
* Various unsafe `as_` casts for point/size/rect.
This will aid the migration in #4015.
## Validation Steps Performed
* Vertical scrolling works in `DxEngine` ✅
This commit is one of the more difficult rewrites that were necessary as part
of #4015, but still simple enough that it can be done as a separate commit.
The search for the `lastNonSpace` was replaced with a simpler
`std::string_view::find_last_not_of`.
## Validation Steps Performed
ConPTY appears to work ✅
This reverts commit 14098d71f2.
## Summary of the Pull Request
@zadjii-msft found that this is causing persisted windows on a secondary monitor to shrink a little each time. We're choosing to revert this commit until that gets resolved.
## References
#12979
This commit fixes various bugs in our unit/feature test suite:
* 2 tests failed at 150% scale.
* The "null key" (@ on a US keyboard) isn't necessarily Shift+2.
The proper way to get it is with `LOBYTE(VkKeyScanW(0))`
* `InputEngineTest::C0Test` never worked as it overwrote
the loop variable, exiting the loop early
Fixes the following issues:
* `desktopWallpaper` not working
* switching tabs/panes causes the background to flicker
* settings preview having a transparent background
## PR Checklist
* [x] Closes#13002
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
Tested the 3 cases above. ✅
## Summary of the Pull Request
For some reason, the PGO tests (specifically the `RunMakeKillTabs` test) started to fail after #12979 merged. After closer inspection, the test was actually improperly written. We should be using <kbd>ctrl+shift+t</kbd> to open new tabs, not <kbd>alt+shift+t</kbd>. Presumably, the <kbd>alt</kbd> was copied over from the previous test, because they look _very_ similar.
So I went ahead and fixed the test, and it now (1) tests what it's intended to test and (2) doesn't fail. Why did #12979 cause the tests to fail? idk, but it works now.
## References
#10071 - Introduce PGO Tests
## Validation Steps Performed
Ran PGO tests locally and confirmed that it works.
Ran PGO pipeline and confirmed that it works.
When the buffer is resized with a reflow, we were previously calculating
the new virtual bottom based on the position of last non-space
character. If the viewport was largely blank when resized, this could
result in the new virtual bottom being higher than it should be.
This PR attempts to address that problem by restoring the virtual bottom
to a position that is the same distance from the cursor row as it was
prior to the resize.
This was a regression introduced in PR #12972.
We still take the last non-space row into account when determining the
virtual bottom, because if the content of the screen is forced to wrap,
the virtual bottom will need to be lower (relative to the cursor) than
it was before.
We also need to check that we don't overflow the bottom of the buffer,
which can occur when the viewport is at the bottom of the buffer, and
the cursor position is pushed down as a result of content wrapping above
it.
I've manually confirmed that this fixes the problem reported in issue
#13078, and I've also extended the existing `RefreshWithReflow` unit
test to cover that particular scenario.
Closes#13078
The `DECAC` (Assign Colors) escape sequence controls which color table
entries are associated with the default foreground and background
colors. This is how you would change the default colors on the the
original DEC VT525 terminals.
But `DECAC` also allows you to assign the color table entries for the
"window frame", which in our case is mapped to the tab color (just the
background for now). So this now gives us a way to control the tab color
via an escape sequence as well.
DETAILS
-------
The way this works is there are now two new entries in the color table
for the frame colors, and two new aliases in the color alias table that
are mapped to those color table entries. As previously mentioned, only
the background is used for now.
By default, the colors are set to `INVALID_COLOR`, which indicates that
the system colors should be used. But if the user has set a `tabColor`
property in their profile, the frame background will be initialized with
that value instead.
And note that some of the existing color table entries are now
renumbered for compatibility with XTerm, which uses entries 256 to 260
for special colors which we don't yet support. Our default colors are
now at 261 and 262, the frame colors are 263 and 264, and the cursor
color is 265.
So at runtime, you can change the tab color programmatically by setting
the color table entry at index 262 using `OSC 4` (assuming you need a
specific RGB value). Otherwise if you just want to set the tab color to
an existing color index, you can use `DECAC 2`.
You can even make the tab color automatically match background color by
mapping the frame background alias to the color table entry for the
default background, using `DECAC 2;261;262` (technically this is mapping
both the the foreground and background).
This PR doesn't include support for querying the color mapping with
`DECRQSS`, and doesn't support resetting the colors with `RIS`, but
hopefully those can be figured out in a future PR - there are some
complications that'll need to be resolved first.
## Validation Steps Performed
I've added a basic unit test that confirms the `DECAC` escape sequence
updates the color aliases in the render settings as expected. I've also
manually confirmed that the tab color in Windows Terminal is updated by
`DECAC 2`, and the default colors are updated in both conhost and WT
using `DECAC 1`.
Closes#6574
Fixes the SUI background being red in high contrast mode. The issue was
that `SolidBackgroundFillColorTertiary` purposefully has a bad High
Contrast color[^1].
The fix was to be explicit in the theme resources so that
`SolidBackgroundFillColorTertiary` is used in light and dark mode, but
the standard high contrast one is used in high contrast mode. Since the
page is the top-level XAML element in the Editor project, I had to
introduce this in the App.xaml resources so that the page can find the
theme resource.
Closes#13065Closes#13070
[^1]: 40df43a61c/dev/CommonStyles/Common_themeresources_any.xaml (L650-L651)
## Summary of the Pull Request
When calculating the position of the virtual bottom after a resize with
reflow, it was possible for it to end up less than the height of the
viewport. This meant that the top of the virtual viewport would be
negative, which resulted in other operations failing further down the
line. This PR updates the virtual bottom calculation to fix that
scenario.
## References
This was probably a regression introduced in PR #12972.
## PR Checklist
* [x] Closes#13034
* [x] CLA signed.
* [x] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #13034
## Validation Steps Performed
I wasn't able to replicate the exact case described in issue #13034,
because I don't have Windows 11, so can't configure the default
terminal. However, I was able to reproduce a similar failure using a
`SetConsoleScreenBufferInfoEx` call, and I've confirmed that this PR
has fixed that.
I've also added another screen buffer test to make sure the
`ResizeWithReflow` method doesn't shrink the virtual bottom when
resizing at the top of the buffer.
When we start up, our window is initially just a frame with a transparent content area. We're gonna do all this startup init on the UI thread, so the UI won't actually paint till it's all done. This results in a few frames where the frame is visible, before the page paints for the first time, before any tabs appears, etc.
To mitigate this, we're gonna wait for the UI thread to finish everything it's gotta do for the initial init, and _then_ fire our Initialized event. By waiting for everything else to finish (`CoreDispatcherPriority::Low`), we let all the tabs and panes actually get created. In the window layer, we're gonna ~cloak~ just not show the window till this event is fired, so we don't actually see this frame until we're actually all ready to go. **This will result in the window seemingly not loading as fast**, but it will actually take exactly the same amount of time before it's usable.
I also experimented with drawing a solid BG color before the initialization is finished. However, there are still a few frames after the frame is displayed before the XAML content first draws, so that didn't actually resolve any issues.
* [x] Closes#11561
* [x] Tested manually
* [x] I work here.
* [x] Accidentally also closes#9053. By switching the initial call from `ShowWindow(SW_SHOW)` to `ShowWindow(SW_SHOWDEFAULT)`, we actually obey the startup info now.
Adds the `selectAll` action which can be used to select all text in the buffer (regardless of whether a selection is present).
## References
#3663 - Mark Mode
#4993 - [Scenario] Keyboard selection
## PR Checklist
* [x] Closes#1469
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
I've made it such that selecting the "entire buffer" really just selects up to the mutable viewport. This seems like a nice QOL improvement since there's generally nothing past that.
When the user selects all, the viewport does not move. This is consistent with CMD behavior and is intended to allow the user to not lose context when selecting everything.
A minor change had to be made to the DxRenderer because this uncovered an underflow issue. Basically, the selection rects were handed to the DxEngine relative to the viewport (which means that some had a negative y-value). At some point, those rects were stored into `size_t`s, resulting in an underflow issue. This caused the renderer to behave strangely when rendering the selection. Generally, these kinds of issues weren't really noticed because selection would always modify a portion of the viewport.
Funny enough, in a way, this satisfies the "mark mode" scenario because the user now has a way to initiate a selection using only the keyboard. Though this isn't ideal, just a fun thing to point out (that's why I'm not closing the mark mode issue).
## Validation Steps Performed
- Verified using DxEngine and AtlasEngine
- select all --> keyboard selection --> start moving the top-left endpoint (and scroll to there)
- select all --> do not scroll automatically
Turns out if you add that Delete handler there, then every time you navigate to the profile, we'll add another Delete handler to the list of handlers. That's bad - that'll cause us to try and delete the profile multiple times.
The repro I had before was 100%, now it's fixed.
* [x] Closes#13017
`TextAttribute` and `TextColor` are commonly used structures in hot paths.
This commit replaces more complex comparisons where each field is compared
independently with a single call to `memcmp`. This compiles down to just
a few instructions. This reduces code and binary size and improves
performance for paths were `TextAttribute`s need to be compared.
## PR Checklist
* [x] Supports #10563
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
* termbench still works ✔️
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
## Summary of the Pull Request
As discussed in team sync. Ignore `newTab` actions with a profile index greater than the number of profiles.
## PR Checklist
* [x] Closes#11114
* [x] I work here
* [ ] Tests added/passed
* [ ] Requires documentation to be updated - maybe❓
In classic fashion, we never run the LocalTests locally before committing, so stuff breaks from time to time.
This time, the main trick was that the tests had a pretty hardcore dependency on the inner workings of `_PreviewActionHandler`, and when that changed, they broke.
Also, there was a weird crash I saw when I had the default terminal set to the Dev build version. That crash would let the test contents pass, but ultimately fail when TAEF tore down the conhost. Unsetting that fixed the crash 🤷Closes#12158
## Summary of the Pull Request
When `TerminalDispatch` was merged with `AdaptDispatch` in PR #13024,
that broke the Terminal's `EraseAll` operation in the alt buffer. The
problem was that the `EraseAll` implementation makes a call to
`SetViewportPosition` which wasn't taking the alt buffer into account,
and thus modified the main viewport instead.
This PR corrects that mistake. If we're in the alt buffer, the
`SetViewportPosition` method now does nothing, since the alt buffer
viewport should always be at 0,0.
## References
This was a regression introduced in PR #13024.
## PR Checklist
* [x] Closes#13038
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #13038
## Validation Steps Performed
I've confirmed that the test case reported in issue #13038 is no longer
failing. I've also made sure the `ED 2` and `ED 3` sequences are still
working correctly in the main buffer.
To quote an internal wiki:
> It generally provides improved footprint and performance over the
> existing default heap for native win32 applications.
It is apparently the default heap on ARM64, and for all UWPs.
This heap has different allocation and compaction characteristics.
I am not sure how it will impact terminal.
## Summary of the Pull Request
Make sure we set `Name` and `FullDescription` on expander-style settings in the SUI
## PR Checklist
* [x] Closes#13019
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Accessibility insights now shows the name/full description for the expander-style settings
## Summary of the Pull Request
This PR replaces the `TerminalDispatch` class with the `AdaptDispatch` class from conhost, so we're no longer duplicating the VT functionality in two places. It also gives us a more complete VT implementation on the Terminal side, so it should work better in pass-through mode.
## References
This is essentially part two of PR #12703.
## PR Checklist
* [x] Closes#3849
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #12662
## Detailed Description of the Pull Request / Additional comments
The first thing was to give the `ConGetSet` interface a new name, since it's now no longer specific to conhost. I went with `ITerminalApi`, since that was the equivalent interface on the terminal side, and it still seemed like a generic enough name. I also changed the way the api is managed by the `AdaptDispatch` class, so it's now stored as a reference rather than a `unique_ptr`, which more closely matches the way the `TerminalDispatch` class worked.
I then had to make sure that `AdaptDispatch` actually included all of the functionality currently in `TerminalDispatch`. That meant copying across the code for bracketed paste mode, the copy to clipboard operation, and the various ConEmu OSC operations. This also required a few new methods to the `ConGetSet`/`ITerminalApi` interface, but for now these are just stubs in conhost.
Then there were a few thing in the api interface that needed cleaning up. The `ReparentWindow` method doesn't belong there, so I've moved that into `PtySignalInputThread` class. And the `WriteInput` method was too low-level for the Terminal requirements, so I've replaced that with a `ReturnResponse` method which takes a `wstring_view`.
It was then a matter of getting the `Terminal` class to implement all the methods in the new `ITerminalApi` interface that it didn't already have. This was mostly mapping to existing functionality, but there are still a number of methods that I've had to leave as stubs for now. However, what we have is still good enough that I could then nuke the `TerminalDispatch` class from the Terminal code and replace it with `AdaptDispatch`.
One oddity that came up in testing, though, was the `AdaptDispatch` implementation of `EraseAll` would push a blank line into the scrollback when called on an empty buffer, whereas the previous terminal implementation did not. That caused problems for the conpty connection, because one of the first things it does on startup is send an `ED 2` sequence. I've now updated the `AdaptDispatch` implementation to match the behavior of the terminal implementation in that regard.
Another problem was that the terminal implementation of the color table commands had special handling for the background color to notify the application window that it needed to repaint the background. I didn't want to have to push the color table operations through the `ITerminalApi` interface, so I've instead moved the handling of the background update into the renderer, initiated by a flag on the `TriggerRefreshAll` method.
## Validation Steps Performed
Surprisingly this PR didn't require a lot of changes to get the unit tests working again. There were just a few methods used from the original `ITerminalApi` that have now been removed, and which needed an equivalent replacement. Also the updated behavior of the `EraseAll` method in conhost resulted in a change to the expected cursor position in one of the screen buffer tests.
In terms of manual testing, I've tried out all the different shells in Windows Terminal to make sure there wasn't anything obviously wrong. And I've run a bunch of the tests from _vttest_ to try and get a wider coverage of the VT functionality, and confirmed everything still works at least as well as it used to. I've also run some of my own tests to verify the operations that had to be copied from `TerminalDispatch` to `AdaptDispatch`.
`InteractivityOneCore` and `RendererWddmCon` were the last two remaining
projects which are relevant for our internal console builds, but couldn't be
easily compiled publicly by users on GitHub. This commit adds all definitions
required to compile the two projects into dysfunctional libraries at least.
(Since the added definitions are deliberately incorrect.)
Additionally this commit fixes the AuditMode build for the two projects.
## Validation Steps Performed
The two new projects compile fine.
As noted in the issue. There's a case where backing up the `lineEnd` can result in the `lineEnd` pointing at exactly the `lineBegin`, which results in an empty view, which causes all sorts of pain later.
Instead, just return early in this case.
* tested with an 80x24 conhost
* tested with an 79x24 conhost
I also tried making this a FAILFAST or a THROW_HR, but the failfast immediately died (of course it did), and the throw would result in a few frames where the composition was just... entirely not displayed? Probably not what we wanted.
* [x] Closes#12730
Modified the scope of input control, it used to be `Text`, now it is
`AlphanumericHalfWidth`. This input scope actually accepts any
characters, but English characters are preferred, and the soft keyboard
also displays English by default.
This should improve user friendliness for users using composition mode
input methods.
As a user who uses the composition mode input method, in applications
like windows terminal that should usually be input in English, it is
always required to manually switch to English mode by pressing Shift
before entering commands.
One keystroke is not a problem, but often for some reason there is no or
no successful switching, and additional more keystrokes are required to
clear the wrong input.
The input method that comes with windows will automatically switch to
English mode for a few programs such as conhost, but windows terminal is
not in this list.
This change should have no negative impact. Even if someone does tend to
use a shell oriented towards composition characters or non-alpha
letters, there should also were more users who in the same language are
more inclined to English characters shells, for example, cmd,
powershell, bash that comes with windows.
If there's any reason to have to keep the Text inputScope, maybe making
this setting customizable via `settings.json` would be a good idea, but
I don't see the need to do this, `AlphanumericHalfWidth` is perfect.
Closes#12731
`_api.cellCount` caches the `TextBuffer` size in AtlasEngine.
Calculating it based on the `_api.sizeInPixel` is incorrect as the
`TextBuffer` size doesn't necessarily have to be the size of the window.
This can occur when the window is resized, as the main thread is receiving its
`WM_SIZE` message and resizing the `TextBuffer` concurrently with the render
thread performing a render pass and AtlasEngine checking the `GetClientRect`.
In order to inform `AtlasEngine` about the initial buffer size, `Renderer`
was modified to also invoke `UpdateViewport()` on the first render cycle.
The only other user of `UpdateViewport()` is `VtEngine` which used to call
`InvalidateAll()` in these situations. In order to prevent the `InvalidateAll()`
call, `VtEngine::UpdateViewport()` was modified to suppress this.
## Validation Steps Performed
* Resizing wide characters doesn't crash the terminal anymore ✅
* The additional call to `UpdateViewport()` doesn't break VtEngine ✅
There are 3 en-dashes`(U+2013)` in the file when they should be hyphen `(U+002D)`.
This character causes the file to fail to compile in a non-utf8 encoding environment.
Just modified 3 characters to make it fall within the scope of ascii and keep it consistent with other files of the project.
The "virtual bottom" marks the last line of the mutable viewport area,
which is the part of the buffer that VT sequences can write to. This
region should typically only move downwards as new lines are added to
the buffer, but there were a number of cases where it was incorrectly
being moved up, or moved down further than necessary. This PR attempts
to fix that.
There was an earlier, unsuccessful attempt to fix this in PR #9770 which
was later reverted (issue #9872 was the reason it had to be reverted).
PRs #2666, #2705, and #5317 were fixes for related virtual viewport
problems, some of which have either been extended or superseded by this
PR.
`SetConsoleCursorPositionImpl` is one of the cases that actually does
need to move the virtual viewport upwards sometimes, in particular when
the cmd shell resets the buffer with a `CLS` command. But when this
operation "snaps" the viewport to the location of the cursor, it needs
to use the virtual viewport as the frame of reference. This was
partially addressed by PR #2705, but that only applied in
terminal-scrolling mode, so I've now applied that fix regardless of the
mode.
`SetViewportOrigin` takes a flag which determines whether it will also
move the virtual bottom to match the visible viewport. In some case this
is appropriate (`SetConsoleCursorPositionImpl` being one example), but
in other cases (e.g. when panning the viewport downwards in the
`AdjustCursorPosition` function), it should only be allowed to move
downwards. We can't just not set the update flag in those cases, because
that also determines whether or not the viewport would be clamped, and
we don't want change that. So what I've done is limit
`SetViewportOrigin` to only move the virtual bottom downwards, and added
an explicit `UpdateBottom` call in those places that may also require
upward movement.
`ResizeWindow` in the `ConhostInternalGetSet` class has a similar
problem to `SetConsoleCursorPositionImpl`, in that it's updating the
viewport to account for the new size, but if that visible viewport is
scrolled back or forward, it would end up placing the virtual viewport
in the wrong place. So again the solution here was to use the virtual
viewport as the frame of reference for the position. However, if the
viewport is being shrunk, this can still result in the cursor falling
below the bottom, so we need an additional check to adjust for that.
This can't be applied in pty mode, though, because that would break the
conpty resizing operation.
`_InternalSetViewportSize` comes into play when resizing the window
manually, and again the viewport after the resize can end up truncating
the virtual bottom if not handled correctly. This was partially
addressed in the original code by clamping the new viewport above the
virtual bottom under certain conditions, and only in terminal scrolling
mode. I've replaced that with a new algorithm which links the virtual
bottom to the visible viewport bottom if the two intersect, but
otherwise leaves it unchanged. This applies regardless of the scrolling
mode.
`ResizeWithReflow` is another sizing operation that can affect the
virtual bottom. This occurs when a change of the window width requires
the buffer to be reflowed, and we need to reposition the viewport in the
newly generated buffer. Previously we were just setting the virtual
bottom to align with the new visible viewport, but that could easily
result in the buffer truncation if the visible viewport was scrolled
back at the time. We now set the virtual bottom to the last non-space
row, or the cursor row (whichever is larger). There'll be edge cases
where this is probably not ideal, but it should still work reasonably
well.
`MakeCursorVisible` was another case where the virtual bottom was being
updated (when requested with a flag) via a `SetViewportOrigin` call.
When I checked all the places it was used, though, none of them actually
required that behavior, and doing so could result in the virtual bottom
being incorrectly positioned, even after `SetViewportOrigin` was limited
to moving the virtual bottom downwards. So I've now made it so that
`MakeCursorVisible` never updates the virtual bottom.
`SelectAll` in the `Selection` class was a similar case. It was calling
`SetViewportOrigin` with the `updateBottom` flag set when that really
wasn't necessary and could result in the virtual bottom being
incorrectly set. I've changed the flag to false now.
## Validation Steps Performed
I've manually confirmed that the test cases in issue #9754 are working
now, except for the one involving margins, which is bigger problem with
`AdjustCursorPosition` which will need to be addressed separately.
I've also double checked the test cases from several other virtual
bottom issues (#1206, #1222, #5302, and #9872), and confirmed that
they're still working correctly with these changes.
And I've added a few screen buffer tests in which I've tried to cover as
many of the problematic code paths as possible.
Closes#9754
## Summary of the Pull Request
Ensures the tab close button color matches the text color.
## PR Checklist
* [x] Closes#13010
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
Also re-ordered and aligned the properties cleared in the `_ClearTabBackgroundColor()` method to match `_ApplyTabColor()`.
## Validation Steps Performed
Manually tested
This pull request introduces a packaging phase that emits
Microsoft.Windows.Console.ConPTY, a nuget package that contains the
pseudoconsole API as well as the requisite copies of conhost.
* winconpty learned to load a version of OpenConsole.exe specific to the
processor architecture on its hosting machine
* the package, as well as its contents, is signed properly and is nearly
ready for distribution via nuget.org
* the API in conpty-static.h has been adjusted to expose
CreatePseudoConsoleAsUser and stamp out the correct DLL import/export
annotations.
* getting .NET to play right was somewhat challenging, but I tested this
against .NET 6.0 and it seemed to work properly; it shipped conpty.dll
in the right places, and it shipped OpenConsole.exe next to the
published application.
In the future, we could provide an interop assembly for C# consumers;
that is, unfortunately, out of scope today.
Closes#3577Closes#3568
Obsoletes #1130
Propagate show/hide window calls against the ConPTY pseudo window to the Terminal
## PR Checklist
* [x] Closes#12570
* [x] I work here
* [x] Manual Tests passed
* [x] Spec Link: →[Doc Link](https://github.com/microsoft/terminal/blob/dev/miniksa/msgs/doc/specs/%2312570%20-%20Show%20Hide%20operations%20on%20GetConsoleWindow%20via%20PTY.md)←
## Detailed Description of the Pull Request / Additional comments
- See the spec. It's pretty much everything I went through deciding on this.
## Validation Steps Performed
- [x] Manual validation against scratch application calling all of the `::ShowWindow` commands against the pseudo console "fake window" and observing the real terminal window state
If we are building a branch called "release-*", we will also change the
NuGet suffix to "preview". If we don't do that, XES will set the suffix
to "release1" because it truncates the value after the first period. In
general, though, we want to disable the suffix entirely if we're Release
branded while on a release branch.
In effect:
BRANCH / BRANDING | Release | Preview
------------------|------------------------|------------------------
release-* | 1.12.20220427 | 1.13.20220427-preview
all others | 1.14.20220427-mybranch | 1.14.20220427-mybranch
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Fixes#6028
Setting is "experimental.useBackgroundImageForWindow"
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
https://github.com/microsoft/terminal/issues/6028
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [X] Closes#6028
* [X] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated. I read CONTRIBUTING.md, but I'm not sure if a spec is needed for an experimental feature such as this one.
* [ ] Schema updated. I added a JSON key, not sure where I need to update it.
* [X] I've discussed this with core contributors already. Somewhat discussed in https://github.com/microsoft/terminal/issues/6028
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here
## Detailed Description of the Pull Request / Additional comments -->
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Set ` "experimental.useBackgroundImageForWindow": true` and a bg image for one profile, then make splits and tabs and make sure the bg updates accordingly:
I also did the same with the setting off to make sure it still works correctly and didn't break. And I made sure opening the settings tab does not crash or show the bg image.
#4015 requires sweeping changes in order to allow a migration of our buffer
coordinates from `int16_t` to `int32_t`. This commit reduces the size of
future commits by using type inference wherever possible, dropping the
need to manually adjust types throughout the project later.
As an added bonus this commit standardizes the alignment of cv qualifiers
to be always left of the type (e.g. `const T&` instead of `T const&`).
The migration to type inference with `auto` was mostly done
using JetBrains Resharper with some manual intervention and the
standardization of cv qualifier alignment using clang-format 14.
## References
This is preparation work for #4015.
## Validation Steps Performed
* Tests pass ✅
Fixed various small issues:
* Made TabView bottom border span the entire window width
* Made ScrollBar inner thumb rounded again
* Made SplitButton look more like the new add tab button
* Adjusted rename box height (24px, like the official compact sizing height)
* Adjusted caption button colors to match Windows 11
* ColorPicker can now escape window bounds
* Tweaked ColorPicker buttons
This will result in the deletion of the following directories from the OS tree, under `onecore/windows/core/console/open`:
* doc/
* src/tools/MonarchPeasantPackage/
* src/api-ms-win-core-synch-l1-2-0/
* src/tools/ansi-color/
* src/tools/ColorTool/
We have gotten some PoliCheck flags on `doc/` (thanks to Niksa.md), but also the OS build just doesn't need these folders 😄
(cherry picked from commit 27b63ad02a)
Service-Card-Id: 80783789
Service-Version: Inbox
855e136 contains a regression which breaks buffer reflow if wide surrogate
characters are present. This happens because we made use of the
`TextBufferCellIterator` whose increment operator skips 2 cells for wide
characters. This created a "misalignment" in the reflow logic which was written
for cell-wise iteration. This commit fixes the issue, by reverting back to the
previous algorithm without iterators.
Closes#12837
Closes MSFT-38904421
## Validation Steps Performed
* Run ``pwsh -noprofile -command echo "`u{D83D}`u{DE43}"``
* Resizing conhost preserves all contents ✅
* Resizing Windows Terminal doesn't crash it ✅
* Added a test covering this issue ✅
(cherry picked from commit 10b9044120)
Service-Card-Id: 80340091
Service-Version: Inbox
The `cascadia/` directory straight up isn't checked into the OS. So adding a test dependency on code in there was a BAD IDEA.
(cherry picked from commit 4e61be9cd7)
Service-Card-Id: 79863821
Service-Version: Inbox
## THE WHITE WHALE
This is a fairly naive fix for this bug. It's not terribly performant,
but neither is resize in the first place.
When the buffer gets resized, typically we only copy the text up to the
`MeasureRight` point, the last printable char in the row. Then we'd just
use the last char's attributes to fill the remainder of the row.
Instead, this PR changes how reflow behaves when it gets to the end of
the row. After we finish copying text, then manually walk through the
attributes at the end of the row, and copy them over. This ensures that
cells that just have a colored space in them get copied into the new
buffer as well, and we don't just blat the last character's attributes
into the rest of the row. We'll do a similar thing once we get to the
last printable char in the buffer, copying the remaining attributes.
This could DEFINITELY be more performant. I think this current
implementation walks the attrs _on every cell_, then appends the new
attrs to the new ATTR_ROW. That could be optimized by just using the
actual iterator. The copy after the last printable char bit is also
especially bad in this regard. That could likely be a blind copy - I
just wanted to get this into the world.
Finally, we now copy the final attributes to the correct buffer: the new
one. We used to copy them to the _old_ buffer, which we were about to
destroy.
## Validation
I'll add more gifs in the morning, not enough time to finish spinning a
release Terminal build with this tonight.
Closes#32🎉🎉🎉🎉🎉🎉🎉🎉🎉Closes#12567
(cherry picked from commit 855e1360c0)
2022-03-28 13:33:54 -05:00
789 changed files with 24449 additions and 17326 deletions
[allow/*.txt](allow/) | Add words to the dictionary | one word per line (only letters and `'`s allowed) | [allow](https://github.com/check-spelling/check-spelling/wiki/Configuration#allow)
[reject.txt](reject.txt) | Remove words from the dictionary (after allow) | grep pattern matching whole dictionary words | [reject](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-reject)
[patterns/*.txt](patterns/) | Patterns to ignore from checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[candidate.patterns](candidate.patterns) | Patterns that might be worth adding to [patterns.txt](patterns.txt) | perl regular expression with optional comment block introductions (all matches will be suggested) | [candidates](https://github.com/check-spelling/check-spelling/wiki/Feature:-Suggest-patterns)
[line_forbidden.patterns](line_forbidden.patterns) | Patterns to flag in checked lines | perl regular expression (order matters, first match wins) | [patterns](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-patterns)
[expect/*.txt](expect.txt) | Expected words that aren't in the dictionary | one word per line (sorted, alphabetically) | [expect](https://github.com/check-spelling/check-spelling/wiki/Configuration#expect)
[advice.md](advice.md) | Supplement for GitHub comment when unrecognized words are found | GitHub Markdown | [advice](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice)
Note: you can replace any of these files with a directory by the same name (minus the suffix)
and then include multiple files inside that directory (with that suffix) to merge multiple files together.
<!-- See https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples%3A-advice --> <!-- markdownlint-disable MD033 MD041 -->
<details>
<summary>
:pencil2: Contributor please read this
@@ -6,7 +6,7 @@
By default the command suggestion will generate a file named based on your commit. That's generally ok as long as you add the file to your commit. Someone can reorganize it later.
:warning: The command is written for posix shells. You can copy the contents of each `perl` command excluding the outer `'` marks and dropping any `'"`/`"'` quotation mark pairs into a file and then run `perl file.pl` from the root of the repository to run the code. Alternatively, you can manually insert the items...
:warning: The command is written for posix shells. If it doesn't work for you, you can manually _add_ (one word per line) / _remove_ items to `expect.txt` and the `excludes.txt` files.
If the listed items are:
@@ -20,31 +20,29 @@ See the `README.md` in each directory for more information.
:microscope: You can test your commits **without***appending* to a PR by creating a new branch with that extra change and pushing it to your fork. The [check-spelling](https://github.com/marketplace/actions/check-spelling) action will run in response to your **push** -- it doesn't require an open pull request. By using such a branch, you can limit the number of typos your peers see you make. :wink:
<details><summary>:clamp: If you see a bunch of garbage</summary>
If it relates to a ...
<details><summary>well-formed pattern</summary>
<details><summary>If the flagged items are :exploding_head: false positives</summary>
See if there's a [pattern](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns) that would match it.
If items relate to a ...
* binary file (or some other file you wouldn't want to check at all).
If not, try writing one and adding it to a `patterns/{file}.txt`.
Please add a file path to the `excludes.txt` file matching the containing file.
Patterns are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines.
Note that patterns can't match multiline strings.
</details>
<details><summary>binary-ish string</summary>
Please add a file path to the `excludes.txt` file instead of just accepting the garbage.
File paths are Perl 5 Regular Expressions - you can [test](
File paths are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your files.
`^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md](
`^` refers to the file's path from the root of the repository, so `^README\.md$` would exclude [README.md](
../tree/HEAD/README.md) (on whichever branch you're using).
</details>
* well-formed pattern.
If you can write a [pattern](https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns) that would match it,
try adding it to the `patterns.txt` file.
Patterns are Perl 5 Regular Expressions - you can [test](
https://www.regexplanet.com/advanced/perl/) yours before committing to verify it will match your lines.
# Update Lorem based on your content (requires `ge` and `w` from https://github.com/jsoref/spelling; and `review` from https://github.com/check-spelling/check-spelling/wiki/Looking-for-items-locally )
"description":"Sets the file location of the sound played when the application emits a BEL character. If the path is invalid no sound will be played. This property also accepts an array of sounds and the terminal will pick one at random.",
"oneOf":[
{
"type":[
"string",
"null"
]
},
{
"type":"array",
"items":{
"type":"string"
}
}
]
},
"AppearanceConfig":{
"properties":{
"colorScheme":{
@@ -179,7 +197,7 @@
},
"intenseTextStyle":{
"default":"bright",
"description":"Controls how 'intense' text is rendered. Values are \"bold\", \"bright\", \"all\" and \"none\"",
"description":"Controls how 'intense' text is rendered when unfocused. Values are \"bold\", \"bright\", \"all\" and \"none\"",
"enum":[
"none",
"bold",
@@ -300,6 +318,7 @@
"moveFocus",
"movePane",
"swapPane",
"markMode",
"moveTab",
"multipleActions",
"newTab",
@@ -331,8 +350,11 @@
"switchToTab",
"tabSearch",
"toggleAlwaysOnTop",
"toggleBlockSelection",
"toggleFocusMode",
"selectAll",
"setFocusMode",
"switchSelectionEndpoint",
"toggleFullscreen",
"setFullScreen",
"setMaximized",
@@ -344,6 +366,10 @@
"quit",
"adjustOpacity",
"restoreLastClosed",
"addMark",
"scrollToMark",
"clearMark",
"clearAllMarks",
"unbound"
],
"type":"string"
@@ -363,6 +389,15 @@
],
"type":"string"
},
"ScrollToMarkDirection":{
"enum":[
"previous",
"next",
"first",
"last"
],
"type":"string"
},
"ResizeDirection":{
"enum":[
"left",
@@ -712,6 +747,30 @@
"direction"
]
},
"ScrollToMarkAction":{
"description":"Arguments corresponding to a Scroll to Mark Action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"scrollToMark"
},
"direction":{
"$ref":"#/$defs/ScrollToMarkDirection",
"default":"previous",
"description":"The direction to scroll to a mark."
}
}
}
],
"required":[
"direction"
]
},
"SendInputAction":{
"description":"Arguments corresponding to a Send Input Action",
"allOf":[
@@ -819,6 +878,27 @@
}
]
},
"AddMarkAction":{
"description":"Arguments corresponding to an Add Mark Action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"addMark"
},
"color":{
"$ref":"#/$defs/Color",
"default":null,
"description":"If provided, will set the mark's color to the given value."
}
}
}
]
},
"SetColorSchemeAction":{
"description":"Arguments corresponding to a Set Color Scheme Action",
"allOf":[
@@ -1647,6 +1727,16 @@
"description":"When set to true, URLs will be detected by the Terminal. This will cause URLs to underline on hover and be clickable by pressing Ctrl.",
"type":"boolean"
},
"experimental.autoMarkPrompts":{
"default":false,
"description":"When set to true, prompts will automatically be marked.",
"type":"boolean"
},
"experimental.showMarksOnScrollbar":{
"default":false,
"description":"When set to true, marks added to the buffer via the addMark action will appear on the scrollbar.",
"type":"boolean"
},
"disableAnimations":{
"default":false,
"description":"When set to `true`, visual animations will be disabled across the application.",
@@ -1689,6 +1779,11 @@
"description":"Force the terminal to use the legacy input encoding. Certain keys in some applications may stop working when enabling this setting.",
"type":"boolean"
},
"experimental.useBackgroundImageForWindow":{
"default":false,
"description":"When set to true, the background image for the currently focused profile is expanded to encompass the entire window, beneath other panes.",
"type":"boolean"
},
"initialCols":{
"default":120,
"description":"The number of columns displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
@@ -1986,15 +2081,20 @@
"description":"Controls what happens when the application emits a BEL character. When set to \"all\", the Terminal will play a sound, flash the taskbar icon (if the terminal window is not in focus) and flash the window. An array of specific behaviors can also be used. Supported array values include `audible`, `window` and `taskbar`. When set to \"none\", nothing will happen.",
"$ref":"#/$defs/BellStyle"
},
"bellSound":{
"description":"Sets the sound played when the application emits a BEL. When set to an array, the terminal will pick one of those sounds at random.",
"$ref":"#/$defs/BellSound"
},
"closeOnExit":{
"default":"graceful",
"description":"Sets how the profile reacts to termination or failure to launch. Possible values:\n -\"graceful\" (close when exit is typed or the process exits normally)\n -\"always\" (always close)\n -\"never\" (never close).\ntrue and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
"default":"automatic",
"description":"Sets how the profile reacts to termination or failure to launch. Possible values:\n -\"graceful\" (close when exit is typed or the process exits normally)\n -\"always\" (always close)\n -\"automatic\" (behave as \"graceful\" only for processes launched by terminal, behave as \"always\" otherwise)\n -\"never\" (never close).\ntrue and false are accepted as synonyms for \"graceful\" and \"never\" respectively.",
"oneOf":[
{
"enum":[
"never",
"graceful",
"always"
"always",
"automatic"
],
"type":"string"
},
@@ -2109,6 +2209,17 @@
],
"deprecated":true
},
"intenseTextStyle":{
"default":"bright",
"description":"Controls how 'intense' text is rendered. Values are \"bold\", \"bright\", \"all\" and \"none\"",
"enum":[
"none",
"bold",
"bright",
"all"
],
"type":"string"
},
"foreground":{
"$ref":"#/$defs/Color",
"default":"#cccccc",
@@ -2204,7 +2315,10 @@
},
"startingDirectory":{
"description":"The directory the shell starts in when it is loaded.",
"type":"string"
"type":[
"string",
"null"
]
},
"suppressApplicationTitle":{
"description":"When set to true, tabTitle overrides the default title of the tab and any title change messages from the application will be suppressed. When set to false, tabTitle behaves as normal.",
| 2020-06-18 | [1.1] in Windows Terminal Preview | [Windows Terminal Preview 1.1 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-1-release/) |
| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | [Windows Terminal Preview 1.2 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/) |
| 2020-08-31 | [1.3] in Windows Terminal Preview<br>[1.2] in Windows Terminal | [Windows Terminal Preview 1.3 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-3-release/) |
| 2020-09-30 | [1.4] in Windows Terminal Preview<br>[1.3] in Windows Terminal | [Windows Terminal Preview 1.4 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-4-release/) |
| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | [Windows Terminal Preview 1.5 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-5-release/) |
| 2021-01-31 | [1.6] in Windows Terminal Preview<br>[1.5] in Windows Terminal | [Windows Terminal Preview 1.6 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-6-release/) |
| 2021-03-01 | [1.7] in Windows Terminal Preview<br>[1.6] in Windows Terminal | [Windows Terminal Preview 1.7 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-7-release/) |
| 2021-04-14 | [1.8] in Windows Terminal Preview<br>[1.7] in Windows Terminal | [Windows Terminal Preview 1.8 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-8-release/) |
| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/) |
| 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-10-release/) |
| 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-11-release/) |
| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-12-release/) |
| | [1.13] in Windows Terminal Preview<br>[1.12] in Windows Terminal | |
| | [1.14] in Windows Terminal Preview<br>[1.13] in Windows Terminal | |
| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | [Windows Terminal Preview 1.2 Release] |
| 2020-08-31 | [1.3] in Windows Terminal Preview<br>[1.2] in Windows Terminal | [Windows Terminal Preview 1.3 Release] |
| 2020-09-30 | [1.4] in Windows Terminal Preview<br>[1.3] in Windows Terminal | [Windows Terminal Preview 1.4 Release] |
| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | [Windows Terminal Preview 1.5 Release] |
| 2021-01-31 | [1.6] in Windows Terminal Preview<br>[1.5] in Windows Terminal | [Windows Terminal Preview 1.6 Release] |
| 2021-03-01 | [1.7] in Windows Terminal Preview<br>[1.6] in Windows Terminal | [Windows Terminal Preview 1.7 Release] |
| 2021-04-14 | [1.8] in Windows Terminal Preview<br>[1.7] in Windows Terminal | [Windows Terminal Preview 1.8 Release] |
| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release] |
| 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release] |
| 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release] |
| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release] |
| 2022-02-03 | [1.13] in Windows Terminal Preview<br>[1.12] in Windows Terminal | [Windows Terminal Preview 1.13 Release] |
| 2022-05-24 | [1.14] in Windows Terminal Preview<br>[1.13] in Windows Terminal | [Windows Terminal Preview 1.14 Release] |
| | [1.15] in Windows Terminal Preview<br>[1.14] in Windows Terminal | |
| | [1.16] in Windows Terminal Preview<br>[1.15] in Windows Terminal | |
| | [1.17] in Windows Terminal Preview<br>[1.16] in Windows Terminal | |
### Release outline
Below is a VERY vague outline of the remaining calendar year that was drafted late May 2022. This was drafted for internal planning purposes, as a guide. It is not meant to represent official dates. More often than not, releases are synced to official features landing, rather than arbitrary dates. Drift from this initial draft is entirely expected.
```mermaid
gantt
title Proposed Terminal Releases 1.14-1.18
dateFormat YYYY-MM-DD
axisFormat %d %b
section Terminal 1.14
Lock down & bake :done, 2022-05-06, 2w
Release 1.14 :milestone, 2022-05-24
section Terminal 1.15
Features :done, a1, 2022-05-06, 4w
Bugfix :active, a2, after a1 , 1w
Lock down & bake :after a2 , 1w
Release 1.15 :milestone, 2022-06-21, 0
1.15 becomes Stable :milestone, after b3, 0
section Terminal 1.16
Features :b1, after a2, 4w
Bugfix :b2, after b1 , 2w
Lock down & bake :b3, after b2 , 2w
Release 1.16 :milestone, after b3, 0
1.16 becomes Stable :milestone, after c3, 0
section Terminal 1.17
Features :c1, after b2, 4w
Bugfix :c2, after c1 , 2w
Lock down & bake :c3, after c2 , 2w
Release 1.17 :milestone, after c3, 0
1.17 becomes Stable :milestone, after d3, 0
section Terminal 1.18
Features :d1, after c2, 4w
Bugfix :d2, after d1 , 2w
Lock down & bake :d3, after d2 , 2w
Release 1.18 :milestone, after d3, 0
```
## Issue Triage & Prioritization
Incoming issues/asks/etc. are triaged several times a week, labeled appropriately, and assigned to a milestone in priority order:
@@ -62,7 +102,9 @@ Incoming issues/asks/etc. are triaged several times a week, labeled appropriatel
# Show Hide operations on GetConsoleWindow via PTY
## Abstract
To maintain compatibility with command-line tools, utilities, and tests that desire to
manipulate the final presentation window of their output through retrieving the raw
console window handle and performing `user32` operations against it like [ShowWindow](https://docs.microsoft.com//windows/win32/api/winuser/nf-winuser-showwindow),
we will create a compatibility layer that captures this intent and translates it into
the nearest equivalent in the cross-platform virtual terminal language and implement the
understanding of these sequences in our own Windows Terminal.
## Inspiration
When attempting to enable the Windows Terminal as the default terminal application on Windows
(to supersede the execution of command-line utilities inside the classic console host window),
we discovered that there were a bunch of automated tests, tools, and utilities that relied on
showing and hiding the console window using the `::GetConsoleWindow()` API in conjunction with
`::ShowWindow()`.
When we initially invented the ConPTY, we worked to ensure that we built to the common
denominator that would work cross-platform in all scenarios, avoiding situations that were
dependent on Windows-isms like `user32k` including the full knowledge of how windowing occurs
specific to the Windows platform.
We also understood that on Windows, the [**CreateProcess**](https://docs.microsoft.com/windows/win32/procthread/process-creation-flags) API provides ample flags specifically
for command-line applications to command the need for (or lack thereof) a window on startup
such as `CREATE_NEW_CONSOLE`, `CREATE_NO_WINDOW`, and `DETACHED_PROCESS`. The understanding
was that people who didn't need or want a window, or otherwise needed to manipulate the
console session, would use those flags on process creation to dictate the session. Additionally,
the `::CreateProcess` call will accept information in `STARTUPINFO` or `STARTUPINFOEX` that
can dictate the placement, size, and visibility of a window... including some fields specific
to console sessions. We had accepted those as ways applications would specify their intent.
Those assumptions have proven incorrect. Because it was too easy to just `::CreateProcess` in
the default manner and then get access to the session after-the-fact and manipulate it with
APIs like `::GetConsoleWindow()`, tooling and tests organically grew to make use of this process.
Instead of requesting up front that they didn't need a window or the overhead of a console session,
they would create one anyway by default and then manipulate it afterward to hide it, move it off-
screen, or otherwise push it around. Overall, this is terrible for their performance and overall
reliability because they've obscured their intent by not asking for it upfront and impacted their
performance by having the entire subsystem spin up interactive work when they intend to not use it.
But Windows is the place for compatibility, so we must react and compensate for the existing
non-ideal situation.
We will implement a mechanism to compensate for these that attempts to capture the intent of the
requests from the calling applications against the ConPTY and translates them into the "universal"
Virtual Terminal language to the best of its ability to make the same effects as prior to the
change to the new PTY + Terminal platform.
## Solution Design
Overall, there are three processes involved in this situation:
1. The client command-line application utility, tool, or test that will manipulate the window.
1. The console host (`conhost.exe` or `openconsole.exe`) operating in PTY mode.
1. The terminal (`windowsterminal.exe` when it's Windows Terminal, but could be a third party).
The following diagram shows the components and how they will interact.
1. The command-line tool calls `::GetConsoleWindow()` on the PTY host
2. The PTY host returns the raw `HWND` to the *Hidden Fake PTY Window* in its control
3. The command-line tool calls `::ShowWindow()` on the `user32.dll` API surface to manipulate that window.
4.`user32.dll` sends a message to the window message queue on the *Fake PTY Window*
5. The PTY host retrieves the message from the queue and translates it to a virtual terminal message
6. The Windows Terminal connection layer receives the virtual terminal message and decodes it into a window operation.
7. The true displayed *Windows Terminal Window* is told to change its status to show or hide.
8. The changed Show/Hide status is returned to the back-end on completion.
9. The Windows Terminal connection layer returns that information to the PTY host so it can remain in-the-know.
10. The PTY updates its *Fake PTY Window* status to match the real one so it continues to receive appropriate messages from `user32`.
This can be conceptually understood in a few phases:
- The client application grabs a handle and attempts to send a command via a back-channel through user32.
- User32 decides what message to send based on the window state of the handle.
- The message is translated by the PTY and propagated to the true visible window.
- The visible window state is returned back to the hidden/fake window to remain in synchronization so the next call to user32 can make the correct decision.
The communication between the PTY and the hosting terminal application occurs with a virtual terminal sequence.
Fortunately, *xterm* had already invented and implemented one for this behavior called **XTWINOPS** which means
we should be able to utilize that one and not worry about inventing our own Microsoft-specific thing. This ensures
that there is some precedence for what we're doing, guarantees a major third party terminal can support the same
sequence, and induces a high probability of other terminals already using it given *xterm* is the defacto standard
for terminal emulation.
Information about **XTWINOPS** can be found at [Xterm control sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html). Search for *XTWINOPS*.
The sequence is **CSI***Ps*; *Ps*; *Ps***t**. It starts with the common "control sequence initiator" of `ESC [` (`0x1B 0x5B`).
Then between 1 and 3 numerical parameters are given, separated by semicolons (`0x3B`).
And finally, the sequence is terminated with `t` (`0x74`).
Specifically, the two parameter commands of `1` for *De-iconify window* and `2` for *Iconify window* appear relevant to our interests.
In `user32` parlance, "iconify" traditionally corresponds to minimize/restore state and is a good proxy for overall visibility of the window.
The theory then is to detect when the assorted calls to `::ShowWindow()` against the *Fake PTY Window* are asking for a command that
maps to either "iconify" or "deiconify" and translate them into the corresponding message over the VT channel to the attached terminal.
To detect this, we need to use some heuristics inside the [window procedure](https://docs.microsoft.com/windows/win32/winmsg/window-procedures) for the window owned by the PTY.
Unfortunately, calls to `::ShowWindow()` on research with the team that owns `user32` do not go straight into the window message queue. Instead, they're dispatched straight into `win32k` to be analyzed and then trigger an array of follow on window messages into the queue depending on the `HWND`'s current state. Most specifically, they vary based on the `WS_VISIBLE` state of the `HWND`. (See [Window Styles](https://docs.microsoft.com/windows/win32/winmsg/window-styles) for details on the `WS_VISIBLE` flag.)
I evaluated a handful of messages with the help of the IXP Essentials team to see which ones would telegraph the changes from `::ShowWindow()` into our window procedure:
- [WM_QUERYOPEN](https://docs.microsoft.com/windows/win32/winmsg/wm-queryopen) - This one allows us to accept/reject a minimize/restore call. Not really useful for finding out current state
- [WM_SYSCOMMAND](https://docs.microsoft.com/windows/win32/menurc/wm-syscommand) - This one is what is called when the minimize, maximize/restore, and exit buttons are called in the window toolbar. But apparently it is not generated for these requests coming from outside the window itself through the `user32` APIs.
- [WM_SHOWWINDOW](https://docs.microsoft.com/windows/win32/winmsg/wm-showwindow) - This one provides some insight in certain transitions, specifically around force hiding and showing. When the `lParam` is `0`, we're supposed to know that someone explicitly called `::ShowWindow()` to show or hide with the `wParam` being a `BOOL` where `TRUE` is "show" and `FALSE` is "hide". We can translate that into *de-iconify* and *iconify* respectively.
- [WM_WINDOWPOSCHANGING](https://docs.microsoft.com/windows/win32/winmsg/wm-windowposchanging) - This one I evaluated extensively as it looked to provide us insight into how the window was about to change before it did so and offered us the opportunity to veto some of those changes (for instance, if we wanted to remain invisible while propagating a "show" message). I'll detail more about this one in a sub-heading below.
- [WM_SIZE](https://docs.microsoft.com/windows/win32/winmsg/wm-size) - This one has a `wParam` that specifically sends `SIZE_MINIMIZED` (`1`) and `SIZE_RESTORED` (`0`) that should translate into *iconify* and *de-iconify respectively.
#### WM_WINDOWPOSCHANGING data
In investigating `WM_WINDOWPOSCHANGING`, I built a table of some of the states I observed while receiving messages from an external caller that was using `::ShowWindow()`:
- integer - The value of the Show Window constant `SW_*` (see [ShowWindow](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-showwindow))
- constant - The name of the Show Window constant
- flags - The `lParam` field is a pointer to a [**WINDOWPOS**](https://docs.microsoft.com/windows/win32/api/winuser/ns-winuser-windowpos) structure during this message. This the `UINT flags` field of that structure.
- Should Hide? - Whether or not I believe that the window should hide if this constant is seen. (Conversely, should show on the opposite.)
- minimizing - This is the `BOOL` response from a call to [**IsIconic()**](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-isiconic) during this message.
- maximizing - This is the `BOOL` response from a call to [**IsZoomed()**](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-iszoomed) during this message.
- showing - This is whether `SWP_SHOWWINDOW` is set on the `WINDOWPOS.flags` field during this message.
- hiding - This is whether `SWP_HIDEWINDOW` is set on the `WINDOWPOS.flags` field during this message.
- activating - This is the inverse of whether `SWP_NOACTIVATE` is set on the `WINDOWPOS.flags` field during this message.
- Remaining headings are `flags` values expanded to `X` is set and blank is unset. See [**SetWindowPos()**](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-setwindowpos) for the definitions of all the flags.
From this data collection, I noticed a few things:
- The data in this table was unstable. The fields varied depending on the order in which I called the various constants against `ShowWindow()`. This is just one particular capture.
- Some of the states, I wouldn't see any message data at all (`SW_HIDE` and `SW_FORCEMINIMIZE`).
- There didn't seem to be a definitive way to use this data to reliably decide when to show or hide the window. I didn't have a reliable way of pulling this together with my *Should Hide?* column.
On further investigation, it became apparent that the values received were sometimes not coming through or varying because the `WS_VISIBLE` state of the `HWND` affected how `win32k` decided to dispatch messages and what values they contained. This is where I determined that steps #8-10 in the diagram above were going to be necessary: to report the state of the real window back to the *fake window* so it could report status to `user32` and `win32k` and receive state-appropriate messages.
For reporting back #8-10, I initially was going to use the `XTWINOPS` call with parameter `11`. The PTY could ask the attached terminal for its state and expect to hear back an answer of either `1` or `2` in the same format message depending on the state. However, on further consideration, I realized that the real window could change at a moments notice without prompting from the PTY, so I instead wrote the PTY to always listen for this and had the Windows Terminal send this back down unprompted.
#### Refined WM_SHOWWINDOW and WM_SIZE data
Upon setting up the synchronization for #8-10, I then tried again to build the table using just the two window messages that were giving me reliable data: `WM_SHOWWINDOW` and `WM_SIZE`:
|integer|constant|Should Hide?|`WM_SHOWWINDOW` OR `WM_SIZE` reported hide?|
|---|---|---|---|
|0|`SW_HIDE`|YES|YES|
|1|`SW_NORMAL`|NO|NO|
|2|`SW_SHOWMINIMIZED`|YES|YES|
|3|`SW_SHOWMAXIMIZED`|NO|NO|
|4|`SW_SHOWNOACTIVATE`|NO|NO|
|5|`SW_SHOW`|NO|NO|
|6|`SW_MINIMIZE`|YES|YES|
|7|`SW_SHOWMINNOACTIVE`|YES|YES|
|8|`SW_SHOWNA`|NO|NO|
|9|`SW_RESTORE`|NO|NO|
|10|`SW_SHOWDEFAULT`|NO|NO|
|11|`SW_FORCEMINIMIZE`|YES|YES|
Since this now matched up perfectly with what I was suspecting should happen *and* it was easier to implement than picking apart the `WM_WINDOWPOSCHANGING` message, it is what I believe the design should be.
Finally, with the *fake window* changing state to and from `WS_VISIBLE`... it was appearing on the screen and showing up in the taskbar and alt-tab. To resolve this, I utilized [**DWMWA_CLOAK**](https://docs.microsoft.com//windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute) which makes the window completely invisible even when in a normally `WS_VISIBLE` state. I then added the [**WS_EX_TOOLWINDOW**](https://docs.microsoft.com/windows/win32/winmsg/extended-window-styles) extended window style to hide it from alt-tab and taskbar.
With this setup, the PTY now has a completely invisible window with a synchronized `WS_VISIBLE` state with the real terminal window, a bidirectional signal channel to adjust the state between the terminal and PTY, and the ability to catch `user32` calls being made against the *fake window* that the PTY stands up for the client command-line application.
## UI/UX Design
The visible change in behavior is that a call to `::ShowWindow()` against the `::GetConsoleWindow()`
handle that is returned by the ConPTY will be propagated to the attached Terminal. As such, a
user will see the entire window be shown or hidden if one of the underlying attached
command-line applications requests a show or hide.
At the initial moment, the fact that the Terminal contains tabbed and/or paned sessions and
therefore multiple command-line clients on "different sessions" are attached to the same window
is partially ignored. If one attached client calls "show", the entire window will be shown with
all tabs. If another calls "hide", the entire window will be hidden including the other tab
that just requested a show. In the opposite direction, when the window is shown, all attached
PTYs for all tabs/panes will be alerted that they're now shown at once.
## Capabilities
### Accessibility
Users of assistive devices will have the same experience that they did with the legacy Windows
Console after this change. If a command-line application decides to show or hide the window
through the API without their consent, they will receive notification of the showing/hiding
window through our UIA framework.
Prior to this change, the window would have always remained visible and there would be no
action.
Overall, the experience will be consistent between what is happening on-screen and what is
presented through the UIA framework to assistive tools.
For third party terminals, it will be up to them to decide what their reaction and experience is.
### Security
We will maintain the security and integrity of the Terminal application chosen for presentation
by not revealing its true window handle information to the client process through the existing
`::GetConsoleWindow()` API. Through our design for default terminal applications, the final
presentation terminal could be Windows Terminal or it could be any third-party terminal that
meets the same specifications for communication. Giving raw access to its `HWND` to a client
application could disrupt its security.
By maintaining a level of separation with this feature by generating a "fake window" in the
ConPTY layer and only forwarding events, the attached terminal (whether ours or a 3rd party)
maintains the final level of control on whether or not it processes the message. This is
improved security over the legacy console host where the tool had full backdoor style access
to all `user32` based window APIs.
### Reliability
This test doesn't improve overall reliability in the system because utilities that are relying
on the behavior that this compatibility shim will restore are already introducing additional
layers of complexity and additional processes into their operation than were strictly necessary
simply by not stating their desires upfront at creation time.
In some capacity, you could argue it increases reliability of the existing tests that were
using this complex behavior in that they didn't work before and they will work now, but
the entire process is fragile. We're just restoring the fragile process instead of having
it not work at all.
### Compatibility
This change restores compatibility with existing applications that were relying on the behavior
we had excluded from our initial designs.
### Performance, Power, and Efficiency
The performance of tooling that is leveraging this process to create a console and then hide
or manipulate the session after the fact will be significantly worse when we enable the
default Windows Terminal than it was with the old Windows Console. This is because the
Terminal is significantly heavier weight (with its modern technologies like WinUI) and
will take more time to start and more committed memory. Additionally, more processes
will be in use because there will be the `conhost.exe` doing the ConPTY translation
and then the `windowsterminal.exe` doing the presentation.
However, this particular feature doesn't do anything to make that better or worse.
The appropriate solution for any tooling, test, or scenario that has a need for
performance and efficiency is to use the flags to `::CreateProcess` in the first place
to specify that they did not need a console window session at all, or to direct its
placement and visibility as a part of the creation call. We are working with
Microsoft's test automation tooling (TAEF) as well as the Windows performance
fundamentals (FUN) team to ensure that the test automation supports creating sessions
without a console window and that our internal performance test suite uses those
specifications on creation so we have accurate performance testing of the operating
system.
## Potential Issues
### Multiple clients sharing the same window host
With the initial design, multiple clients sharing the same window host will effectively
share the window state. Two different tabs or panes with two different client applications
could fight over the show/hide state of the window. In the initial revision, this is
ignored because this feature is being driven by a narrow failure scenario in the test gates.
In the reported scenario, a singular application is default-launched into a singular tab
in a terminal window and then the application expects to be able to hide it after the creation.
In the future, we may have to implement a conflict resolution or a graphical variance to
compensate for multiple tabs.
### Other verbs against the console window handle
This scenario initially focuses on just the `::ShowWindow()` call against the window handle
from `::GetConsoleWindow()`. Other functions from `user32` against the `HWND` will not
necessarily be captured and forwarded to the attached terminal application. And even more
specifically, we're focusing only on the Show and Hide state. Other state modifications that
are subtle related to z-ordering, activation, maximizing, snapping, and so on are not considered.
## Future considerations
### Multiple clients
If the multiple clients problem becomes more widespread, we may need to change the graphical
behavior of the Windows Terminal window to only hide certain tabs or panes when a command
comes in instead of hiding the entire window (unless of course there is only one tab/pane).
We may also need to adjust that once consensus is reached among tabs/panes that it can then
and only then propagate up to the entire window.
We will decide on this after we receive feedback that it is a necessary scenario. Otherwise,
we will hold for now.
### Other verbs
If it turns out that we discover tests/scenarios that need maximizing, activation, or other
properties of the `::ShowWindow()` call to be propagated to maintain compatibility, we will
be able to carry those through on the same channel and command. Most of them have an existing
equivalent in `XTWINOPS`. Those that do not, we would want to probably avoid as they will not
be implemented in any other terminal. We would extend the protocol as an absolute last resort
and only after receiving feedback from the greater worldwide terminal community.
### Z-ordering
The channel we're establishing here to communicate information about the window and its
placement may be useful for the z-ordering issues we have in #2988. In those scenarios,
a console client application is attempting to launch and position a window on top of the
terminal, wherever it is. Further synchronizing the state of the new fake-window in the
ConPTY with the real window on the terminal side may enable those tools to function as
they expect.
This is another circumstance we didn't expect: having command-line applications create windows
with a need for complex layout and ordering. These sorts of behaviors cannot be translated
to a universal language and will not be available off the singular machine, so encouraged
alternative methods like command-line based UI. However, for single-box scenarios, this
behavior is engrained in some Windows tooling due to its ease of use.
// Note: will through if unable to allocate char/attribute buffers
#pragma warning(push)
#pragma warning(disable : 26447) // small_vector's constructor says it can throw but it should not given how we use it. This suppresses this error for the AuditMode build.
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
