I don't actually know why this is happening, because it doesn't
happen with startup actions specified in the settings file.
In any case, it's fixed with more delays.
Closes#18572
## Validation Steps Performed
* Create a tab with 2 panes
* Tear it off into a new window
* New window has 1 tab with 2 panes ✅
Missed a few `_getTerminalPosition()` on the first run. Disabled
rounding for pointer movements and mouse wheel events (which are used
for hyperlink hover detection and vt mouse mode). The only time we round
now is...
- `SetEndSelectionPoint()` --> because we're updating a selection
- `ControlCore->LeftClickOnTerminal()` --> where all paths are used for
selection*
*the only path that doesn't is `RepositionCursorWithMouse` being
enabled, which also makes sense based on clicking around Notepad with a
large font size.
## References and Relevant Issues
Follow-up for #18486Closes#18595
## Validation Steps Performed
In large font size, play around with midnight commander and hover over
hyperlink edges.
* `_ApplyLanguageSettingChange` calls `PrimaryLanguageOverride`
(the WinRT API function) and we would call it every time a new
window is created. Now it's only called on settings load.
* `_RegisterTabEvents` would listen for "Content" changes which can
be null. `IVector::Append` throws if a null object is given.
In our case, it's null if the content got erased with nothing.
Additionally, this fixes a bug where we wouldn't call
`_ProcessLazySettingsChanges` on startup. This is important if the
settings file was changed while Windows Terminal wasn't running.
Lastly, there's a lifetime fix in this PR, which is a one-line change
and I didn't want to make a separate PR for that.
When the server handle gets closed on conhost (= terminal is gone),
and e.g. PowerShell is used, we would previously log 6 error messages.
This PR reduces it to zero, by removing the 3 biggest offenders.
## Summary of the Pull Request
There's already logic to tab to a hyperlink when we're in mark mode. We
do this by looking at the automatically detected hyperlinks and finding
the next one of interest. This adds an extra step afterwards to find any
embedded hyperlinks and tab to them too.
Since embedded hyperlinks are stored as text attributes, we need to
iterate through the buffer to find the hyperlink and it's buffer
boundaries. This PR tries to reduce the workload of that by first
finding the automatically detected hyperlinks (since that's a fairly
quick process), then using the reduced search area to find the embedded
hyperlink (if one exists).
## Validation Steps Performed
In PowerShell, add an embedded hyperlink as such:
```powershell
${ESC}=[char]27
Write-Host "${ESC}]8;;https://github.com/microsoft/terminal${ESC}\This is a link!${ESC}]8;;${ESC}\"
```
Enter mark mode (ctrl+shift+m) then shift+tab to it.
✅ The "This is a link!" is selected
✅ Verified that this works when searching forwards and backwards
Closes#18310Closes#15194
Follow-up from #13405
OSC 8 support added in #7251
WinUI asynchronously updates its tab view items, so it may happen that
we're given a `TabViewItem` that still contains a `TabBase` which has
actually already been removed. Regressed in #15924.
Closes#18581
## Validation Steps Performed
* Close tabs rapidly with middle click
* No crash ✅
This is a theoretical fix for #18584 as I cannot reproduce the issue
anymore. It did happen briefly on one of my devices though, and at the
time I observed that it would persist a window with no startup actions.
Found this one completely randomly.
## Validation Steps Performed
* Open 2 windows with 1 tab each
* Click the X button on the tab in the 1st window
* OpenConsole/etc. is cleaned up ✅
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
During startup we relinquish ownership of the console lock to wait for
the DA1 response of the hosting terminal. The problem occurs if the
hosting terminal disconnects during that time. The broken pipe will
cause `VtIo` to send out `CTRL_CLOSE_EVENT` messages, but those won't
achieve anything, because the first and only client hasn't even finished
connecting yet. What we need to do instead is to return an error code.
In order to not use a bunch of booleans to control this behavior, I gave
`VtIo` a state enum. This however required restructuring the calling
code in order to not have a dozen states.
## Validation Steps Performed
* Launch cmd.exe with ConPTY
* ...but leave the stdin pipe unbound (which will hang the DA1 request)
* Immediately kill the ConPTY session
* cmd.exe exits after clicking away the error message ✅
Before we had a Settings UI, we added support for a setting called
`startOnUserLogin`. It was a boolean, and on startup we would try to
yeet the value of that setting into the Windows API responsible for
registering us as a startup task.
Unfortunately, we failed to take into account a few things.
- Startup tasks can be independently controlled by the user in Windows
Settings or by an enterprise using enterprise policy
- This control is not limited to *disabling* the task; it also supports
enabling it!
Users could enable our startup task outside the settings file and we
would never know it. We would load up, see that `startOnUserLogin` was
`false`, and go disable the task again. 🤦
Conversely, if the user disables our task outside the app _we can never
enable it from inside the app._ If an enterprise has configured it
either direction, we can't change it either.
The best way forward is to remove it from our settings model and only
ever interact with the Windows API.
This pull request replaces `startOnUserLogin` with a rich settings
experience that will reflect the current and final state of the task as
configured through Windows. Terminal will enable it if it can and
display a message if it can't.
My first attempt at this PR (which you can read in the commit history)
made us try harder to sync the state between the settings model and the
OS; we would propagate the disabled state back to the user setting when
the task was disabled in the OS or if we failed to enable it when the
user asked for it. That was fragile and didn't support reporting the
state in the settings UI, and it seems like it would be confusing for a
setting to silently turn itself back off anyway...
Closes#12564
Fixes an issue on Windows 10 where icon on selected color chips would be
missing in the NullableColorPicker.
Fixes (or at least significantly improves the experience) text being
truncated for the special colors in the NullableColorPicker. This was
done by removing the word "Use" from the labels and adding a visual
state trigger to change the layout of the chips and buttons when the
window becomes narrow.
Related to #18318
Campbell has been the default color scheme for a long time now,
but it has quite some issues with hue and chroma.
This PR introduces a new scheme which was created using the Oklab
color space to find colors with maximal distance to each other
and well distributed and consistent hue and chroma.
Because of this, I've named the scheme after the creator of Oklab.
Closes#17818
When Sixel images are rendered, they're automatically scaled to match
the 10x20 cell size of the original hardware terminals. If this requires
the image to be scaled down, the default GDI stretching mode can produce
ugly visual artefacts, particularly for color images. This PR changes
the stretching mode to `COLORONCOLOR`, which looks considerably better,
but without impacting performance.
The initial Sixel implementation was added in PR #17421.
## Validation Steps Performed
I've tested with a number of different images using a small font size to
trigger the downscaling, and I think the results are generally better,
although simple black on white images are still better with the default
mode (i.e. `BLACKONWHITE`), which is understandable.
I've also checked the performance with a variation of the [sixel-bench]
test, and confirmed that the new mode is no worse than the default.
[sixel-bench]: https://github.com/jerch/sixel-bench
Fixes an issue where pressing `CTRL` + `Insert` does not copy text
selected in the Command Palette. Instead, it closes it, and any text
selected in the pane is copied to the clipboard.
Since `Insert` is a virtual key, I address the issue by adding a
conditional check for `CTRL` with either `Insert` or `C` (previously, it
only checked for `CTRL` with `C`) for the copy action in the Command
Palette.
## Validation Steps Performed
I followed the reproduction steps and verified that the actual behaviour
matched the expected behaviour. All existing tests passed, but no new
test was added.
Closes#9520
## Summary of the Pull Request
Fixes a bug where VT mouse mode would round to the nearest cell when
clicking the mouse button.
The fix is to round to the nearest cell only when we're selecting text.
The other scenarios affected are:
- clicking on a hyperlink
- vt mouse mode
- where the context menu is anchored
Really the most notable ones were the first two. So now, we use the
position of the cell we clicked on. We only round for selection.
## References and Relevant Issues
Follow-up to #18106
## Detailed Description of the Pull Request / Additional comments
## Validation Steps Performed
Opened Midnight Commander in Ubuntu and clicked between the two panes.
- Before: threshold was too early to switch between panes
- After: threshold is clearly separated between the outline of the two
panes
---------
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
This PR allows users to enable the tab bar in fullscreen mode.
A new setting; "showTabsFullscreen"; has been added which accepts a
boolean value. When `true`, then the tab bar will remain visible when
the terminal app is fullscreen. If the value is `false` (default), then
the tab bar is hidden in fullscreen.
When the tab bar is visible in fullscreen, the min/max/close controls
are hidden to maintain the expected behaviour of a fullscreen app.
## Validation Steps Performed
All unit tests are passing.
Manually verified that when the "launchMode" setting is "fullscreen" and
the "showTabsFullscreen" setting is `true`, the tab bar is visible on
launch.
Manually verified that changing the setting at runtime causes the tab
bar to be shown/hidden immediately (if the terminal is currently
fullscreen).
Manually verified that the new "showTabsFullscreen" setting is honoured
regardless of whether "showTabsInTitlebar" is set to `true` or `false`.
Closes#11130
Selection is generally stored as an inclusive start and end. This PR
makes the end exclusive which now allows degenerate selections, namely
in mark mode. This also modifies mouse selection to round to the nearest
cell boundary (see #5099) and improves word boundaries to be a bit more
modern and make sense for degenerate selections (similar to #15787).
Closes#5099Closes#13447Closes#17892
## Detailed Description of the Pull Request / Additional comments
- Buffer, Viewport, and Point
- Introduced a few new functions here to find word boundaries, delimiter
class runs, and glyph boundaries.
- 📝These new functions should be able to replace a few other functions
(i.e. `GetWordStart` --> `GetWordStart2`). That migration is going to be
a part of #4423 to reduce the risk of breaking UIA.
- Viewport: added a few functions to handle navigating the _exclusive_
bounds (namely allowing RightExclusive as a position for buffer
coordinates). This is important for selection to be able to highlight
the entire line.
- 📝`BottomInclusiveRightExclusive()` will replace `EndExclusive` in the
UIA code
- Point: `iterate_rows_exclusive` is similar to `iterate_rows`, except
it has handling for RightExclusive
- Renderer
- Use `iterate_rows_exclusive` for proper handling (this actually fixed
a lot of our issues)
- Remove some workarounds in `_drawHighlighted` (this is a boundary
where we got inclusive coords and made them exclusive, but now we don't
need that!)
- Terminal
- fix selection marker rendering
- `_ConvertToBufferCell()`: add a param to allow for RightExclusive or
clamp it to RightInclusive (original behavior). Both are useful!
- Use new `GetWordStart2` and `GetWordEnd2` to improve word boundaries
and make them feel right now that the selection an exclusive range.
- Convert a few `IsInBounds` --> `IsInExclusiveBounds` for safety and
correctness
- Add `TriggerSelection` to `SelectNewRegion`
- 📝 We normally called `TriggerSelection` in a different layer, but it
turns out, UIA's `Select` function wouldn't actually update the
renderer. Whoops! This fixes that.
- TermControl
- `_getTerminalPosition` now has a new param to round to the nearest
cell (see #5099)
- UIA
- `TermControlUIAProvider::GetSelectionRange` no need to convert from
inclusive range to exclusive range anymore!
- `TextBuffer::GetPlainText` now works on an exclusive range, so no need
to convert the range anymore!
## Validation Steps Performed
This fundamental change impacts a lot of scenarios:
- ✅Rendering selections
- ✅Selection markers
- ✅Copy text
- ✅Session restore
- ✅Mark mode navigation (i.e. character, word, line, buffer)
- ✅Mouse selection (i.e. click+drag, shift+click, multi-click,
alt+click)
- ✅Hyperlinks (interaction and rendering)
- ✅Accessibility (i.e. get selection, movement, text extraction,
selecting text)
- [ ] Prev/Next Command/Output (untested)
- ✅Unit tests
## Follow-ups
- Refs #4423
- Now that selection and UIA are both exclusive ranges, it should be a
lot easier to deduplicate code between selection and UIA. We should be
able to remove `EndExclusive` as well when we do that. This'll also be
an opportunity to modernize that code and use more `til` classes.
Apparently, we were using the package containing the CRT _source code_
to determine the version of the tools.
Also apparently, VS does not guarantee that that package has the same
version as the tools package.
We should use the version of the tools package instead.
As explained in the comment on `_getViewportCursorPosition`, printing
to stdout after initiating a cooked stdin reads is a race condition
between the application and the terminal. But we can significantly
reduce the likelihood of this being obvious with this change.
Related to #18265
Possibly related to #18081
## Validation Steps Performed
Execute the following Go code and start typing:
```go
package main
import (
"fmt"
"time"
)
func main() {
go func() {
time.Sleep(50 * time.Millisecond)
fmt.Printf("Here is a prompt! >")
}()
var text string
fmt.Scanln(&text)
}
```
Without this change the prompt will disappear,
and with this change in place, it'll work as expected. ✅
The code in #17909 was not completely right for padding values with
fewer than four components, and it was doing some fragile string math
(that is: if you wanted to change the third element in the padding it
would parse out the whole thing, edit the third value, and then format
it again).
This pull request moves the control's padding parser into cppwinrt_utils
(for lack of a better place) and makes the settings UI use it to parse
the padding out into a `Thickness` as early as possible. Then, the
controls operate directly on the Thickness' members rather than parsing
the padding string again.
To handle two-way serialization properly, we also required a function
that converts a thickness back into a reduced string representation
(i.e. when all four values are N, it will return "N").
As a bonus, this pull request also:
- removes another use of `std::getline`
- fixes an issue where resetting the padding would change it
(infinitesimally) and cause it to be set again
- adds a readout of the current padding value in the expander itself
- removes `MaxValueFromPaddingString`, which was apparently unused
This pull request introduces a new profile setting,
`compatibility.allowOSC52`, which defaults to `true`. When disabled, it
will not allow applications to write to the clipboard.
Security-minded folks may choose to disable it.
Reroutes the `closeWindow` action to use the `CloseWindow()` method like
the window's X button does. This includes logic to display the
confirmation dialog.
Also removes `CloseRequested` as it was only used by this action
handler. We already have `CloseWindowRequested` so we're just using that
instead.
## Validation Steps Performed
✅ `closeWindow` action while multiple tabs opened brings up the
confirmation dialog
Closes#17613
There's an existing WinUI bug where a nested Grid has it's star-sizing
ignored on Windows 10. This resulted in the New Tab Menu page looking
weird on Windows 10. This PR fixes the layout issue by applying a max
width to the first column, which will be clipped as necessary to make
space for the second column.
Part of #18281
## Validation Steps Performed
Validated the page looks good on Windows 10 and Windows 11, even after
resizing the window.
Fixes a few accessibility bugs in the SettingContainer previews. Main
changes include:
- `SettingContainer` was considered a separate UIA element from the
inner expander. It's been marked as `AccessibilityView=Raw` to "remove"
it from the UIA tree.
- Added a `CurrentValueAccessibleName` property to the
`SettingContainer` to expose the current value to the screen reader for
`SettingContainer`s that have expanders. Non-expander
`SetttingContainer`s already worked fine.
- Applied `CurrentValueAccessibleName` to various settings throughout
the settings UI for full coverage. Added a `CurrentValue` for the ones
that were missing it.
- Removed a redundant/hidden tab stop in `Icon`
`Padding` was not updated since #18300 is handling that. This'll just
automatically make it accessible.
Font axes and features weren't updated to show previews, but I'm happy
to do it if given a suggestion.
Part of #18318
## Details
- `SettingContainer` updates:
- `AccessibilityView = Raw` for `SettingContainer`s with expanders. This
is because the expander itself is the one we care about. No need to have
another layer of UIA objects saying it's a group.
- Added a `CurrentValueAccessibleName` property
- This specifically defines what should be read out by the screen
reader, similar to `AutomationProperties.Name`
- It updates automatically when `CurrentValue` changes.
- It's applied on the inner `Expander`, if one exists.
- The accessible name is constructed to be `"<Header>:
<CurrentValueAccessibleName>"`. If `CurrentValueAccessibleName` isn't
provided, we try to use the `CurrentValue` if it's a string.
- Profile (and appearance) settings:
- `Icon`'s value is now read out by a screen reader instead of staying
silent. It'll read the icon path.
- A redundant/hidden tab stop was removed from `Icon`.
- `TabTitle` now displays/reads "None" if no tab title is set.
- `ColorScheme` is now read out by a screen reader.
- The color scheme overrides (i.e. `Foreground`, `Background`,
`SelectionBackground`, and `CursorColor`) are now read out by a screen
reader. Format is "#<hex value>".
- `BackgroundImageAlignment` is now displayed and read out by a screen
reader.
- `LaunchSize` is now displayed and read out by a screen reader. Format
is "Width x Height".
## Validation Steps Performed
Tabbed through the settings UI with a screen reader. Each of these
settings now reads out a preview.
This fixes the bit check for key down and adds a few comments.
Closes#18331
## Validation Steps Performed
Printing the resulting INPUT_RECORDs shows both key down and up events
when pressing F7. Alt-Space now also works again.
The CoreWindow approach to implementing this has proven itself to be bug
prone. This PR switches to using the much better Win32 ShowCursor API,
which uses a reference count. This prevents the exact sort of race
condition we have where we we disable the cursor in our code and the
WinUI code then sets it to a different cursor internally which gets the
system out of sync. There's no WinUI API to just hide the cursor and if
it did, it would probably be a Boolean which would result in the same
issue.
Closes#18400
## Validation Steps Performed
It's difficult to assert the correctness of this approach, outside of
just trying it out (which I did and it works). The good news is that
this uses a static bool to ensure we only hide it exactly once and show
it exactly once and we do the latter on every WM_ACTIVATE message which
should hopefully restore the cursor when tabbing out and back in at
least.
CodeQL is raising errors when building Visual Studio since they have a
dependency on Windows Terminal for our integrated terminal. The issue
raised by CodeQL refers to a non-constant string format, but in this
case the string comes from a resource file and should be considered
constant.
The conhost window uses the window message WM_GETDPISCALEDSIZE to scale
its client rect non-linearly. This is done to keep the rows and columns
from changing when the window changes (font sizes scale non-linearly).
If you size the window such that the text perfectly fits the width (and
cursor is on the first row of the next line), dragging the window
between monitors with different DPIs should NOT change how much of the
text fits on each line.
https://learn.microsoft.com/en-us/windows/win32/hidpi/wm-getdpiscaledsize
The current code is assuming that the size that should be scaled is the
current window size. This is sometimes the case, for example when
dragging a window between monitors, but it is not always the case. This
message can sometimes contain a size that is different from the window's
current size. For example, if the window is maximized, minimized, or
snapped (the size in these cases is the normal rect, or restore rect).
The msdn page above does (now) call this out, though it is possible that
this was added after this conhost code was added...
> The LPARAM is an in/out pointer to a SIZE struct. The _In_ value in
the LPARAM is the pending size of the window after a user-initiated move
or a call to SetWindowPos.
If the window is being resized, this size is not necessarily the same as
the window's current size at the time this message is received.
This incorrect assumption can cause the conhost window to be
unexpectedly large/small in some cases. For example:
1. Requires two monitors, set to different DPIs.
2. Size window somewhat small, and type text to fit exactly the width of
the window, putting cursor on first row of next line.
3. Win+Left (or otherwise snap/arrange the window).
4. Win+Shift+Left (migrates the window to the other monitor)
5. Win+Shift+Down (restore window, can also click maximize caption
button twice, maximizing then restoring)
Expected: The window should restore to the original logical size, with
the text perfectly fitting one line.
Actual: The window restores to another size; it is the snapped size on
the original monitor (the size of the window at the time it was changing
DPI, in step 4 above).
## References and Relevant Issues
This message (WM_GETDPISCALEDSIZE) is not widely used, but it is used by
dialogs (user32!CreateDialog), since they also size their windows using
font sizes. The code in this change borrows from the code in the dialog
manager, user32!GetDialogDpiScaledSize.
## Detailed Description of the Pull Request / Additional comments
The WM_GETDPISCALEDSIZE message contains the new DPI and the new size,
which is an in/out parameter. It starts as the new window size, scaled
to the window's current DPI, and is expected to be scaled to the new
DPI.
The client area (the part with the text) is NOT scaled linearly. For
example, if the font at 100% DPI has a height of 7, it could have a
height of 15 at 200%. (And if it did have a height of 14, linearly
scaled, it would surely not be linearly scaled at 150%, since fonts
cannot have a height of 10.5.) To pick the right size, we need to
resolve the font at the new DPI and use its actual size to scale the
client area.
To keep the amount of text in the window the same, we need to remove the
non-client area of the window (caption bars, resize borders, etc). The
non-client area is outside the area with the text, and its size depends
on the window's DPI and window styles. To remove it and add it back, we
need to:
- Reduce the provided window rect size by the non-client size at the
current DPI.
- Scale the client size using the new/old font sizes.
- Expand the final size by the non-client size at the new DPI.
Fixes
* Cursor vanishing, because
```cpp
CoreWindow::GetForCurrentThread().PointerCursor()
```
returned a non-null, but still invisible cursor.
* Alt/F7 not dispatching to newly created windows, because the
`WM_ACTIVATE` message now arrives before the `AppHost` is initialized.
This caused the messages to be delivered to old windows.
* Windows Terminal blocking expedited shutdown,
because we return `FALSE` on non-`ENDSESSION_CLOSEAPP` messages.
Closes#18331Closes#18335
## Validation Steps Performed
* Cursor still doesn't really vanish for me in the first place ✅
* Alt/F7 work in new windows without triggering old ones ✅
win10-* is no longer a valid rid
https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/8.0/rid-graph
This package would fail to install the dependencies to the correct
location in .net 8 and later by default. win-x64 is a valid runtime id
in prior .net versions so I think this should be back compat.
Without this the package fails to do its job on newer builds unless `
<UseRidGraph>true</UseRidGraph>` and the user sets `win10-x64` as their
RID in their project file.
