Close the tab context menu when clicking on the title bar
## Detailed Description of the Pull Request / Additional comments
Following #2438, hide the tabs context menu on `TerminalPage::TitlebarClicked()`.
We don't know which of the tabs is showing the context menu, do it on all tabs.
## Validation Steps Performed
Open the context menu from any tab, click on title bar and see the context menu disappear.
Closes#7988
We are getting some watson crash reports that the terminal is attempting
to resize to `(0, 0)`. This change makes it so that we prevent such
resizing and if so, throw an exception before we reach native code.
This commit adds resizing checks that prevent resizing the terminal WPF
control to a size of `(0, 0)`
- The number of lines to move upon scroll up scroll down can be defined
in ScrollUp and ScrollDown commands (parameter is called
"rowsToScroll").
- If the number are not provided, use the system default (the one we are
using for mouse scrolls), rather than 1 line.
## Validation Steps Performed
* Manual testing
* Added custom bindings for scroll commands with different values,
verified they and the default appear and behave as expected
* Checked that invalid values are not allowed
Closes#5078
This introduces an addendum to the Terminal Settings Model spec that
covers inheritance and fallback. Basically, settings objects will now
have a reference to a parent object. If the settings object does not
have a setting defined, it will ask its parent to resolve the value. A
parent is set using the `Clone()` function. `Copy()` is used to copy the
value and structure of the settings model, whereas `Clone()` is used to
copy a reference to the settings model and build an inheritance tree.
## References
#6904 - Terminal Settings Model Spec
#1564 - Settings UI
This PR resolves an issue I observed in
Microsoft.Terminal.Wpf.TerminalControl.CalculateMargins(). Specifically,
on line 194 in the project. In this example, the line: `height =
controlSize.Height - (this.TerminalRendererSize.Height /
dpiScale.DpiScaleX);` is associating the height margin with
dpiScale.DpiScaleX instead of dpiScale.DpiScaleY. This PR changes the
association to DpiScaleY.
Closes#8038
The intent of this PR is to resolve the dependency errors reported in
#7931. The Types project has been added as a reference to the
FuzzWrapper project, which fixes the unresolved dependency errors
reported.
For validation steps, I:
1.) Pulled down main.
2.) Rebuilt the FuzzWrapper project and observed the unresolved
dependency errors keeping it from building successfully.
3.) Added a project reference to the Types project.
4.) Rebuilt the FuzzWrapper project and verified that the dependency
errors disappeared.
Closes#7931.
<!-- 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)? -->
Adds the color slider to the tab color picker
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#7948
* [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: #7948
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
*Not required*
We wrap the call to `_WriteSettings` in
`CascadiaSettingsSerialization.cpp` in a try/catch block, and if we
catch an error we append a warning telling the user to check the
permissions on their settings file.
Closes#7727
Our build pipeline was originally set up such that we could take any
binaries from the Terminal build and seamlessly re-package them with the
release or preview livery. My initial plan was to stamp a stable and
preview build at the same time, out of the same bits, to make ring
promotion easier.
I've never done that. For the last five releases, we've just re-cut a
new stable build along with the new preview build, usually because we
want to backport some fixes to stable.
This commit introduces preprocessor defines, detectable through CL and
RC, for any project that wants them. Right now, that's just going to be
WindowsTerminal.vcxproj (since it hosts the icons and the app entry
point). This list may be extended to include wt (the shim executable)
and the shell extension at some future date.
This will greatly simplify the logic in #7971, as we'll no longer need
to detect if we're dev or preview at runtime. It may also simplify the
logic in the shell extension for determining whether we're Dev or not.
## Summary of the Pull Request
Fixes the bug where `exit`ing inside a closed pane would leave the Terminal blank.
Additionally, removes `Tab::GetRootElement` and replaces it with the _observable_ `Tab::Content`. This should be more resilient in the future.
Also adds some tests, though admittedly not for this exact scenario. This scenario requires a cooperating TerminalConnection that I can drive for the sake of testing, and _ain't nobody got time for that_.
## References
* Introduced in #6989
## PR Checklist
* [x] Closes#7252
* [x] I work here
* [x] Tests added/passed 🎉
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
From notes I had left in `Tab.cpp` while I was working on this:
```
OKAY I see what's happening here the ActivePaneChanged Handler in TerminalPage
doesn't re-attach the tab content to the tree, it just updates the title of the
window.
So when the pane is `exit`ed, the pane's control is removed and re-attached to
the parent grid, which _isn't in the XAML tree_. And no one can go tell the
TerminalPage that it needs to re set up the tab content again.
The Page _manually_ does this in a few places, when various pane actions are
about to take place, it'll unzoom. It would be way easier if the Tab could just
manage the content of the page.
Or if the Tab just had a Content that was observable, that when that changed,
the page would auto readjust. That does sound like a LOT of work though.
```
## Validation Steps Performed
Opened panes, closed panes, exited panes, zoomed panes, moved focus between panes, panes, panes, panes
## Summary of the Pull Request
Just deleting an unnecessary call to `_UpdateCommandsForPalette`
**Note:** This only fixes slowdown when opening/closing a tab, but not upon first startup (we still need to call `_UpdateCommandsForPalette` there
## References
Fixes the slowdown described in #7820 for opening and closing tabs, but doesn't improve startup time dramatically.
## Validation Steps Performed
Tested with ~100 profiles in my settings file
This PR changes the ATS display order to _always_ be in most recently
used (MRU) order. I chose not to give ATS the option to be displayed
in-order because that order is better served through the traditional
left-right TabRow switching.
_Note_: `TabSearch` will stay in-order.
This means that users can only choose one order or another in their
`nextTab/prevTab` bindings. Setting `useTabSwitcher` to true will make
nT/pT open the ATS in MRU order. If it's set to false, the ATS won't
open and nT/pT will simply go left and right on the TabRow.
I'm open to getting rid of the global and making ATS its own keybinding,
but for now I figured I would keep the current behavior and open the PR
to get eyes on the code that doesn't have anything to do with the
settings.
Closes#973
Let's assume the user has bound the dead key ^ to a sendInput command
that sends "b". If the user presses the two keys ^a it'll produce "bâ",
despite us marking the key event as handled. We can use `ToUnicodeEx`
to clear such dead keys from the keyboard state and should make use of
that for keybindings. Unfortunately `SetKeyboardState` cannot be used
for this purpose as it doesn't clear the dead key state.
Validation
* Enabled a German keyboard layout
* Added the following two keybindings:
{ "command": { "action": "sendInput", "input": "x" }, "keys": "q" },
{ "command": { "action": "sendInput", "input": "b" }, "keys": "^" }
* Pressed the following keys → ensured that the given text is printed:
* q → x
* ´ → nothing
* a → á
* ^ → b
* a → a (previously this would print: â)
* ´ → nothing
* ^ → b
* a → a (unfortunately we cannot specifically clear only ^)
Closes#5784
Updates the GH Action and makes a small update to the README to test
changes.
A missing install step for Windows Terminal using Scoop has been added.
The versioning of Super-Linter was also switched to v3 to allow
auto-updates within the v3 series. This can be version-pinned again if a
breaking change comes later. The current updates fix some bugs and bump
the linters utilized.
## Validation Steps Performed
Validation will be shown in the build steps.
Closes#7934
Fix for crash occurring when splitting a pane, due to tab context menu created multiple times.
## References
#7728
## PR Checklist
* [x] Closes#7941
* [x] CLA signed.
## Detailed Description of the Pull Request / Additional comments
When splitting panes the `Tab::Initialize` function is called again. This rebuilt the context menu from scratch and appended the existing Close... sub-menu items to a new parent, thus causing the crash.
It is not necessary to re-create the context menu every time you split panes, it can be created only once.
## Validation Steps Performed
Manual verification:
- Play with the context menu, the Close... submenu is functioning
- Split panes (ALT + New tab), no crash occurs and context menu still functioning
## Summary of the Pull Request
This implements the `Copy` function for `CascadiaSettings`. Copy performs a deep copy of a `CascadiaSettings` object. This is needed for data binding in the Terminal Settings Editor.
The `Copy` function was basically implemented in every settings model object. This was mostly just repetitive work.
## References
#7667 - TSM
#1564 - Settings UI
## PR Checklist
* [X] Tests added/passed
It turns out that we missed part of the OSC 8 spec which indicated that
_hyperlinks with the same ID but different URIs are logically distinct._
> Character cells that have the same target URI and the same nonempty id
> are always underlined together on mouseover.
> The same id is only used for connecting character cells whose URIs is
> also the same. Character cells pointing to different URIs should never
> be underlined together when hovering over.
This pull request fixes that oversight by appending the (hashed) URI to
the generated ID.
When Terminal receives one of these links over ConPTY, it will hash the
URL a second time and therefore append a second hashed ID. This is taken
as an acceptable cost.
Fixes#7698
This commit adds a missing conversion utf8 to utf16 in decoding base64
for handling multibyte text in copying via OSC 52.
## Validation Steps Performed
* automatically
* Tests w/ multibyte characters
* manually
* case1
* Executed `printf "\x1b]52;;%s\x1b\\" "$(printf '👍👍🏻👍🏼👍🏽👍🏾👍🏿' | base64)"`
* Verified `👍👍🏻👍🏼👍🏽👍🏾👍🏿` in my clipboard
* case2
* Copied `👍👍🏻👍🏼👍🏽👍🏾👍🏿` by tmux 2.6 default copy function (OSC 52)
* Verified `👍👍🏻👍🏼👍🏽👍🏾👍🏿` in my clipboard
Closes#7819
This optimizes the binary size of the xorg color table by replacing the
static lookup table with a table of variable colors (indexed "" (0)
through "4"), calculated greys for gr[ae]y0-100, and a table of the
remaining unsuffixed colors.
78 variable colors ...
8 bytes each for pointer+size
5 variants, 4 bytes each for the color data
718 bytes for 0-terminated color names
plus
84 colors ...
8 bytes each for pointer+size
4 bytes each for the color data
955 bytes for 8-terminated color names
2902 = (78 * 8) + (78 * 5 * 4) + 718
+ 1963 = (84 * 8) + (84 * 4) + 955
------
4865 bytes (approximately)
"I couldn't sleep at night thinking that after years of accusing Windows
being bloated and literally making it even more bloated with my hands.
So here you go. The mediocre yet working solution. This reduces the
binary size to 1051k (1067k before) while keeping the code maintainable
for human beings."
VsCode uses `>` as its "prefix" for the equivalent of their "action
mode". This PR aligns the Terminal with their logic here.
We have to be tricky - if we use the `>` in the actual input as the
indicator for action mode, we can't display any placeholder text in the
input to tell users to type a command. This wasn't an issue for the
commandline mode previously, because we'd stick the "prompt" in the "no
matches text" space. However, we can't do that for action mode. Instead,
we'll stick a floating text block over the input box, and when the
user's in action mode, we'll manually place a `>` into that space. When
the user backspaces the `>`, we'll remove it from that block, and switch
into commandline mode.
## Validation Steps Performed
Played with the cmdpal in lots of different modes, this finally feels
good
Closes#7736
This PR adds support for the `DECREQTPARM` (Request Terminal Parameters)
escape sequence, which was originally used on the VT100 terminal to
report the serial communication parameters. Modern terminal emulators
simply hardcode the reported values for backward compatibility.
The `DECREQTPARM` sequence has one parameter, which was originally used
to tell the terminal whether it was permitted to send unsolicited
reports or not. However, since we have no reason to send an unsolicited
report, we don't need to keep track of that state, but the permission
parameter does still determine the value of the first parameter in the
response.
The response parameters are as follows:
| Parameter | Value | Meaning |
| ---------------- | ------ | ------------------------ |
| response type | 2 or 3 | unsolicited or solicited |
| parity | 1 | no parity |
| data bits | 1 | 8 bits per character |
| transmit speed | 128 | 38400 baud |
| receive speed | 128 | 38400 baud |
| clock multiplier | 1 | |
| flags | 0 | |
There is some variation in the baud rate reported by modern terminal
emulators, and 9600 baud seems to be a little more common than 38400
baud, but I thought the higher speed was probably more appropriate,
especially since that's also the value reported by XTerm.
## Validation Steps Performed
I've added a couple of adapter and output engine tests to verify that
the sequence is dispatched correctly, and the expected responses are
generated. I've also manually tested in Vttest and confirmed that we now
pass the `DECREQTPARM` test in the _Test of terminal reports_.
Closes#7852
Adds a new setting, `bellStyle`, to be able to disable the audible bell
added in #7679. Currently, this setting accepts two values:
* `audible`: play a noise on a bell
* `none`: Don't play a noise.
In the future, we can add a `"bellStyle": "visible"` for flashing the
Terminal instead of making a noise on bell.
## Validation Steps Performed
Pressing <kbd>Ctrl+G</kbd> in cmd, and hitting enter is an easy way of
triggering a bell. I set the setting to `none`, and presto, the bell
stopped.
Closes#2360
This commit is in support of WTU.
I initially added support for a new flag, `PSEUDOCONSOLE_UNDOCKED_PREFER_INBOX_CONHOST`,
which I liked because it was more explicit. We chose not to go that route.
### Automatic fallback
#### Pros
* It's easier on the consumer
* We can eventually expand it to support `$ARCH/openconsole.exe`
#### Cons
* Packaging the project wrong will result in a working-but-somewhat-broken experience (old conhost)
* We ameliorated this by checking it in the packaging script.
* Implicit behavior may be bad
Terminal ships with this dependency embedded, and it is not required that you install it separately. Since the link is broken, let's just remove it entirely.
* [x] fixes#7889
* [x] related to https://github.com/microsoft/terminal/issues/7917#issuecomment-707955335
* [x] I work here
* [x] is a docs update
Additionally, update the markdown linter rules in the wake of #7637, because apparently that was never actually applied to any files, so now the onus is on the first person to touch any of our markdown files.
This PR introduces a pair of classes for managing VT parameters that
automatically handle range checking and default fallback values, so the
individual operations don't have to do that validation themselves. In
addition to simplifying the code, this fixes a few cases where we were
mishandling missing or extraneous parameters, and adds support for
parameter sequences on commands that couldn't previously handle them.
This PR also sets a limit on the number of parameters allowed, to help
thwart DoS memory consumption attacks.
## References
* The new parameter class also introduces the concept of an
omitted/default parameter which is not necessarily zero, which is a
prerequisite for addressing issue #4417.
## Detailed Description of the Pull Request / Additional comments
There are two new classes provide by this PR: a `VTParameter` class,
similar in function to a `std::optional<size_t>`, which holds an
individual parameter (which may be an omitted/default value); and a
`VTParameters` class, similar in function to `gsl:span<VTParameter>`,
which holds a sequence of those parameters.
Where `VTParameter` differs from `std::optional` is with the inclusion
of two cast operators. There is a `size_t` cast that interprets omitted
and zero values as 1 (the expected behaviour for most numeric
parameters). And there is a generic cast, for use with the enum
parameter types, which interprets omitted values as 0 (the expected
behaviour for most selective parameters).
The advantage of `VTParameters` class is that it has an `at` method that
can never fail - out of range values simply return the a default
`VTParameter` instance (this is standard behaviour in VT terminals). It
also has a `size` method that will always return a minimum count of 1,
since an empty parameter list is typically the equivalent of a single
"default" parameter, so this guarantees you'll get at least one value
when iterating over the list with `size()`.
For cases where we just need to call the same dispatch method for every
parameter, there is a helper `for_each` method, which repeatedly calls a
given predicate function with each value in the sequence. It also
collates the returned success values to determine the overall result of
the sequence. As with the `size` method, this will always make at least
one call, so it correctly handles empty sequences.
With those two classes in place, we could get rid of all the parameter
validation and default handling code in the `OutputStateMachineEngine`.
We now just use the `VTParameters::at` method to grab a parameter and
typically pass it straight to the appropriate dispatch method, letting
the cast operators automatically handle the assignment of default
values. Occasionally we might need a `value_or` call to specify a
non-standard default value, but those cases are fairly rare.
In some case the `OutputStateMachineEngine` was also checking whether
parameters values were in range, but for the most part this shouldn't
have been necessary, since that is something the dispatch classes would
already have been doing themselves (in the few cases that they weren't,
I've now updated them to do so).
I've also updated the `InputStateMachineEngine` in a similar way to the
`OutputStateMachineEngine`, getting rid of a few of the parameter
extraction methods, and simplifying other parts of the implementation.
It's not as clean a replacement as the output engine, but there are
still benefits in using the new classes.
## Validation Steps Performed
For the most part I haven't had to alter existing tests other than
accounting for changes to the API. There were a couple of tests I needed
to drop because they were checking for failure cases which shouldn't
have been failing (unexpected parameters should never be an error), or
testing output engine validation that is no longer handled at that
level.
I've added a few new tests to cover operations that take sequences of
selective parameters (`ED`, `EL`, `TBC`, `SM`, and `RM`). And I've
extended the cursor movement tests to make sure those operations can
handle extraneous parameters that weren't expected. I've also added a
test to verify that the state machine will correctly ignore parameters
beyond the maximum 32 parameter count limit.
I've also manual confirmed that the various test cases given in issues
#2101 are now working as expected.
Closes#2101
## Summary of the Pull Request
Added watch on desktopImagePath to check when the path equals "DesktopWallpaper"
If it does equal "DesktopWallpaper" it replaces the path with a path to the desktop's wallpaper
*I am a student and this is my first pull request for Terminal so please give feedback no matter how small. It's the best way I can learn.
## PR Checklist
* [X] Closes#7295
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [?] Tests added/passed
* [X] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: https://github.com/MicrosoftDocs/terminal/pull/155
* [?] Schema updated. (Not sure if this is needed, also not sure where this would be)
* [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: #7295 (Have only talked with the people on the issue, which I don't think has any core contributors)
## Detailed Description of the Pull Request / Additional comments
I am using SystemParametersInfo for SPI_GETDESKWALLPAPER which puts the path into a WCHAR and that is then inserted as the BackgroundImagePath.
I do not think an additional test would add value. The SPI_GETDESKTOPWALLPAPER uses the computers local wallpaper path and puts it into a WCHAR, which then I feed into BackgroundImagePath() as it's new path. I don't think there adds value in making a static path of the desktop background and testing that, given that static tests are already done for "BackgroundImage()".
## Validation Steps Performed
(Manual Validation - Test False Value)
1. Ran Terminal
2. Set setting ["backgroundImage": "<some random img path>"] under profiles->defaults
3. Verified terminal's background is not the desktops wallpaper.
(Manual Validation - Test True Value)
1. Ran Terminal
2. Set setting ["backgroundImage": "DesktopWallpaper"] under profiles->defaults
3. Verified the background image matches the desktop background image.
(Manual Validation - Multiple Tabs True Value)
1. Ran Terminal
2. Set setting ["backgroundImage": "DesktopWallpaper"] under profiles->defaults
3. Verified the background image matches the desktop background image.
4. Opened new tabs
5. Verified the background image matches the desktop background image for each tab.
For whatever reason, the super linter seems to think that any file it doesn't recognize is an EDITORCONFIG file. That means all our `cpp`, `hpp`, `h`, `resw`, `xaml`, etc files are going to get linted with different rules than the clang-format ones we already use.
This PR disables the EDITORCONFIG linter, and has a minimal change to a cpp file to ensure that it's no longer linted by the action.
See also:
* #7637 added this
* #7799 is blocked by this
* #7924 is blocked by this
<!-- 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
Add a "Close..." option to the tab context menu, with nested entries to close tabs to the right and close other tabs (actions already available)
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#1912
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#5524
* [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
<!-- 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
First contribution 🙂
Tried to follow some suggestions from https://github.com/microsoft/terminal/issues/1912#issuecomment-667079311
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
This uses the templates from
https://github.com/github/super-linter/tree/master/TEMPLATES currently.
A future PR can add the necessary templates to the Windows Terminal
repository and update the source of Templates following the README.
Additionally we can add flags to explicitly choose the linters
applicable to this code base but is not necessary.
Per the README, this does not enforce any linting rules but rather
outputs the suggestions in the build step, which are to be read by the
PR submitter and Windows Terminal team to determine if they want to use
the linting rule. C++ is currently not supported (Powershell, Json,
Yaml, and Markdown will be the only things the linter checks for
currently) but we could add our own custom support if desired in
separate PR.
## Validation Steps Performed
It successfully runs. Currently only shows the yaml file itself being
linted in this PR as a test case. It will apply to new PRs once this is
merged. We can lint existing code base but would require a separate PR
and examining the code output (also requires updating the yaml file
temporarily).
Closes#7513
* Correct the behaviour of parsing `rgb:R/G/B`. It should be interpreted
as `RR/GG/BB` instead of `0R/0G/0B`
* Add support for `rgb:RRR/GGG/BBB` and `rgb:RRRR/GGGG/BBBB`. The
behaviour of 12 bit variants is to repeat the first digit at the end,
e.g. `rgb:123/456/789` becomes `rgb:1231/4564/7897`.
* Add support for `#` formats. We are following the rules of
[XParseColor] by interpreting `#RGB` as `R000G000B000`.
* Add support for XOrg app color names, which are supported by xterm, VTE
and many other terminal emulators.
* Multi-parameter OSC 4 is now supported.
* The chaining of OSC 10-12 is not yet supported. But the parameter
validation is relaxed by parsing the parameters as multi-params but
only use the first one, which means `\e]10;rgb:R/G/B;` and
`\e]10:rgb:R/G/B;invalid` will execute `OSC 10` with the first color
correctly. This fixes some of the issues mentioned in #942 but not
all of them.
[XParseColor]: https://linux.die.net/man/3/xparsecolorCloses#3715
This commit introduces two new launch modes: focus and maximizedFocus.
* Focused mode, behaves like a default mode, but with the Focus Mode
enabled.
* Maximized focused mode, behaves like a Maximized mode, but with the
Focus Mode enabled.
There two ways to invoke these new modes:
* In the settings file: you set the "launchMode" to either "focus" or
"maximizedFocus"
* In the command line options, you can path -f / --focus, which is
mutually exclusive with the --fullscreen, but can be combined with the
--maximized:
* Passing -f / --focus will launch the terminal in the "focus" mode
* Passing -fM / --focus --maximized will launch the terminal in the
"maximizedFocus" mode
This should resolve a relevant part in the command line arguments
mega-thread #4632Closes#7124Closes#7825Closes#7875
Took this as an easy starter. The method IslandWindow::SetAlwaysOnTop is
triggered once terminal settings are reloaded (in
TerminalPage::_RefreshUIForSettingsReload flow). This method calls
SetWindowPos without SWP_NOACTIVATE. As a result the window gets
activated, the focus is set and the cursor starts blinking.
Added SWP_NOACTIVATE in all SetWindowPos calls from IslandWindow and
NoClientIslandWindow (where it was missing). Please let me know if this
is an overkill - it is not required to fix the issue, however seems a
good practice, that might help if we decide to apply more settings
immediately.
## Validation Steps Performed
* Only manual testing - please guide me to the relevant UT framework, if
exists.
* Trying to reproduce this with VS attached doesn't work - the window
gets the focus in any case.
* Tested as a standalone application, by modifying different settings
(and comparing the results before and after the fix).
* Checked with Spy++ that no WM_ACTIVATE / WM_SETFOCUS is thrown upon
settings modification
* Applied terminal resizing, toggling full screen and focus mode to
check no regression was introduced.
Closes#7571
Adds a tooltip to the new tab button and menu to let the user know
that holding alt will open a new pane instead.
Fixes#7851
Co-authored-by: Pankaj Bhojwani <pabhojwa@microsoft.com>
Adds the ability to manually handle the terminal renderer resizing
events by allowing different render size and WPF control size. This is
done by adding an `AutoFill` property to the control that prevents the
renderer from automatically resizing and tells the WPF control to fill
in the extra space with the terminal background as shown below:
This PR adds the following:
- Helper method in the DX engine to convert character viewports into
pixel viewports
- `AutoFill` property that prevents automatic resizing of the renderer
- Tweaks and fixes that automatically fill in the empty space if
`AutoFill` is set to false
- Fixes resizing methods and streamlines their codepath
## Validation Steps Performed
Manual validation with the Visual Studio Integrated Terminal tool
window.
This pull request introduces (a very, very stripped-down copy of) the
WIL fallback error reporter.
It emits error records, usually immediately before the application
implodes, into the event stream.
This should improve diagnosability of issues that take Terminal down,
and allow us to give out a .wprp file to gather traces from users.
`ScrollIntoView` is responsible for scrolling the viewport to include
the UTR's start endpoint. The crash was caused by `start` being at the
exclusive end, and attempting to scroll to it. This is now fixed by
clamping the result to the bottom of the buffer.
Most of the work here is to allow a test for this. `ScrollIntoView`
relied on a virtual `ChangeViewport` function. By making that
non-virtual, the `DummyElementProvider` in the tests can now be a
`ScreenInfoUiaProviderBase`. This opens up the possibility of more
UiaTextRange tests in the future too.
Closes#7839
