## Summary of the Pull Request
Fixes a bug where the edit button in the actions page would have white text when in light theme. Now, we just fallback to XAML's built-in value (black in light theme and white in dark theme).
## References
#6900 - Epic
Closes#10406
This commit makes the feature staging header build in OS razzle.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev cd1428ce557238663b7a748763ea8ce082b88256
Related work items: MSFT-33722503
## Summary of the Pull Request
This commit fixes various race conditions regarding the settings UI. It's unsafe to write to class members from background threads without acquiring mutexes or yielding to the main thread first.
By changing the settings reload code path to yield to the main thread early, we're able to cut down on code complexity and unsafe member accesses.
## PR Checklist
* [x] Closes#9273
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Settings UI reloads without crashing ✔️
This pull request converts four of our existing `#ifdef` (or `#ifndef`)
`INSIDE_WINDOWS` blocks to til::features:
* Attempting to establish a handoff session (inside Windows only)
* The ability to *receive* a handoff session (outside Windows only)
* The DX engine (outside Windows only) and shaders (also outside only)
* Whether we use numpad event synthesis for clipboard/conpty (inside
Windows only)
Most of these are using the preprocessor verison of til::feature, only
because it is more difficult to gate the inclusion of headers on
constant expressions. I'd love to prefer the compile time version.
## Summary of the Pull Request
This PR adds a global "language" setting, which may be set to any supported BCP 47 tag.
Additionally a ComboBox is added to the settings UI under "Appearance", listing all languages with their localized names.
This PR introduces one new issue: If you change the language while the app is running, the UI will be in a torn state, as not all UI elements refresh automatically if the `PrimaryLanguageOverride` is changed.
## PR Checklist
* [x] Closes#5497
* [x] I work here
* [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
* [x] Schema updated
## Validation Steps Performed
* UI language changes when changing the "language" in settings.json before starting WT / while WT is running. ✔️
* "language" field is removed from settings.json if "Use system default" is selected. ✔️
* "language" field is added or updated in settings.json if any other language is selected. ✔️
* Removes qps- languages if debugFeatures is false. ✔️
* Correctly refreshes all UI elements with the new language. ❌
This pull request implements a "feature flagging" system that will let
us turn Terminal and conhost features on/off by branch, "release" status
or branding (Dev, Preview, etc.).
It's loosely modelled after the Windows OS concept of "Velocity," but
only insofar as it is driven by an XML document and there's a tool that
emits a header file for you to include.
It only supports toggling features at compile time, and the feature flag
evaluators are intended to be fully constant expressions.
Features are added to `src\features.xml` and marked with a "stage". For
now, the only stages available are `AlwaysDisabled` and `AlwaysEnabled`.
Features can be toggled to different states using branch and branding
tokens, as documented in the included feature flag docs.
For a given feature Feature_XYZ, we will emit two fixtures visible to
the compiler:
1. A preprocessor define `TIL_FEATURE_XYZ_ENABLED` (usable from MIDL,
C++ and C)
2. A feature class type `Feature_XYZ` with a static constexpr member
`IsEnabled()` (usable from C++, designed for `if constexpr()`).
Like Velocity, we rely on the compiler to eliminate dead code caused by
things that compile down to `if constexpr (false)`. :)
Michael suggested that we could use `WindowsInbox` as a branding to
determine when we were being built inside Windows to supplant our use of
the `__INSIDE_WINDOWS` preprocessor token. It was brilliant.
Design Decisions
----------------
* Emitting the header as part of an MSBuild project
* WHY: This allows the MSBuild engine to ensure that the build is
only run once, even in a parallel build situation.
* Only having one feature flag document for the entire project
* WHY: Ease.
* Forcibly including `TilFeatureStaging` with `/FI` for all CL compiler
invocations.
* WHY: If this is a project-wide feature system, we should make it as
easy as possible to use.
* Emitting preprocessor definitions instead of constexpr/consteval
* WHY: Removing entire functions/includes is impossible with `if
constexpr`.
* WHY: MIDL cannot use a `static constexpr bool`, but it can rely on
the C preprocessor to remove text.
* Using MSBuild to emit the text instead of PowerShell
* WHY: This allows us to leverage MSBuild's `WriteOnlyWhenDifferent`
task parameter to avoid changing the file's modification time when
it would have resulted in the same contents. This lets us use the
same FeatureStaging header across multiple builds and multiple
branches and brandings _assuming that they do not result in a
feature flag change_.
* The risk in using a force-include is always that it, for some
reason, determines that the entire project is out of date. We've
gone to great lengths to make sure that it only does so if the
features _actually materially changed_.
## Summary of the Pull Request
Fixes a bug where top-level iterable commands were not serialized.
## PR Checklist
* [X] Closes#10365
* [X] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
- `Command::ToJson`:
- iterable commands deserve the same treatment as nested commands
- `ActionMap`:
- Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.
Add missing keys to the schema:
- globalSummon (and args: desktop, monitor, name, dropdownDuration, toggleVisibility)
- quakeMode
- iterateOn
- commands
Also enforces required keys for commands and deprecates "keybindings"
## PR Checklist
* [x] Closes#7443
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Schema updated.
## Detailed Description of the Pull Request / Additional comments
There were some other pending keys mentioned on the issue, but I don't think they are pending anymore.
## Validation Steps Performed
Changed the `"$schema"` value in my settings.json to point to the edited one.
#### ⚠️ This targets #10051
## Summary of the Pull Request
This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.
While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.
## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5
## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.
* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
- It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.
Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).
## Validation Steps Performed
The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>
(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
Summon, not toggle visibility, window on command line dispatch
## PR Checklist
* [x] Closes#10292
* [x] I work here
* [x] Manual test
## Detailed Description of the Pull Request / Additional comments
- This is the same as #10389, just a different route. I didn't realize it at the time.
## Validation Steps Performed
- Opened a window. Dispatched the `wt -w 0 - p <profile>` and watched it join/summon instead of minimize the active WT.
The flyout wasn't very polished, so I did some adjustments.
It's all visual changes, functionality should be the same.
* made the flyout use OverlayCornerRadius and 16px padding (to match WinUI 2.6)
* changed ColorPicker to muxc:ColorPicker for new styles (the color schemes picker too)
* changed "Custom" Button into a ToggleButton
* no longer needs ellipsis - localization files should be updated
* OK button was moved to the right and uses accent color
* adjusted margins and padding
* tweaked the color boxes to _look_ like the ones in color schemes
 
## Validation Steps Performed
* Color picker in settings UI still works ✔️
* Color picker for tabs still works ✔️
Activate window only (no toggle) when inbound connection arrives
## PR Checklist
* [x] Closes#10386
* [x] I work here
* [x] Manual test passed.
## Detailed Description of the Pull Request / Additional comments
The default for the `SummonWindowBehavior` is a toggle of the visibility state. I didn't realize that. We do not want that for inbound connections. We want always-brought-to-front.
## Validation Steps Performed
- Made the change. Launched Terminal as default as active window. Runbox'd another command. It didn't hide itself like it used to. Stays visible.
This PR adds a new PercentageSignConverter that appends the percentage sign to a number. The new converter is being used by the Acrylic opacity slider label and the Background image opacity slider label.
* [x] Closes#10289
## PR Checklist
* [x] Closes random crash that @lhecker sent me on Teams
* [x] I work here.
## Detailed Description of the Pull Request / Additional comments
- Any change to the renderer engine has to be done under lock. Leonard gave me a crash where the dirty rectangles changed out from under the renderer thread. By inspection, only one spot in `ControlCore` is modifying the engine outside of lock.... here. The dump is too far along to definitively prove the issue and it's sort of a race so its difficult to repro. But the theory is sound that all writes to the dirty regions must be done under lock. So here's a fix.
Restore embedded manifests to say 18362 or unpackaged activation won't work (for helix testing.)
## PR Checklist
* [x] Closes#10265
* [x] I work here
* [x] Tests now pass
## Detailed Description of the Pull Request / Additional comments
- Unpackaged activation uses the embedded manifest inside the exe. We use unpackaged activation to run our tests in Helix as it's easier that way. Turns out the 1903/19h1 OS thinks 19041 isn't greater than the minimum XAML islands version of 18226 and blocks the load of `TerminalApp.dll` causing a crash (fail fast) on launch. For **REASONS**, 18362 is considered greater than 18226.
- Packaged activation will use the value in the .appxmanifest and everything is somehow still fine there even with it saying 19041 now.
## Validation Steps Performed
- Kicking a Helix-run off on this branch: https://dev.azure.com/ms/terminal/_build/results?buildId=177336&view=results
Restore helix runs by passing parameters
## PR Checklist
* [x] Closes#10266
* [x] I work here
* [x] Tests added/passed
## Detailed Description of the Pull Request / Additional comments
It looks like at some point the configuration and platform variables got messed up passing into the Helix steps and preventing the Powershell scripts from setting up the Helix payload correctly. This restores them to functionality.
## Validation Steps Performed
- Ran it in the pipeline
## Summary of the Pull Request
Incremental linking was disabled for debug builds only by mistake in the past.
It can't hurt to have it enabled for debug builds.
## PR Checklist
* [x] I work here
* [x] Project still builds
Update profiles schema to draft 2020-12 because as mentioned in https://github.com/microsoft/vscode/issues/98724#issuecomment-786502628, OpenAPI Specification 3.1 defines using JSON Schema 2020-12 and VS Code already has early implementation around it.
Basically, this just gets rid of the following error shown by VS Code when editing the settings.json file
```
Draft 2019-09 schemas are not yet fully supported.
```
## PR Checklist
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Schema updated.
Docs have been updated (for bug fixes/features)
docs update => proper capitalisation would be better. 👍: Github
## PR Checklist
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
### Other information:
Signed-off-by: Ayushman Singh Chauhan <ascb508@gmail.com>
Applies feedback from https://github.com/microsoft/terminal/pull/9949#pullrequestreview-662590658
Highlights include:
- bugfix: make all edit buttons stay visible if the user is using assistive technology
- rename a few functions and resources to match the correct naming scheme
- update the localized text for a conflicting key chord being assigned
- provide better comments throughout the actions page code
## References
#9949 - Original PR
Closes#10168
Just come cleanup I did not manage to get to before #9270 merged.
Specifically:
- We only initialize the animation and timer if we need them
- We don't repeatedly destroy/create the timer
## Validation Steps Performed
It still works
## Summary of the Pull Request
When the `runformat` script was updated to include xaml formatting, the new code failed to work if run from anywhere other than the project root. This PR updates the script so it can be run from anywhere.
## PR Checklist
* [x] Closes#9768
* [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
## Detailed Description of the Pull Request / Additional comments
There were a couple of places in the script where it was collecting the list of xaml files by doing `git ls-files **/*.xaml`. That obviously relies on the code being executed from within the root of the project. I've now updated those queries to prefix the path with the `$root` variable, which points to the project root.
## Validation Steps Performed
I've run the `runformat` script from within the tools directory and confirmed that it now works correctly from there. I've tested by changing some formatting in both .cpp and .xaml files, and also saved some .xaml files with a BOM to make sure those were appropriately stripped.
C++/WinRT has a way to ensure that we use `make<>` instead of allocating
WinRT objects on the stack, but until 10.0.19041 the XAML compiler
generated code that violated that rule.
Because of how make detection is implemented, it must create a derived
type (and so WinRT implementation types can't be `final`).
I cannot for the life of me repro the original bug. I've got fonts with bad permissions SxS, I've tried installing a font twice, I've tried stopping the font cache service. No idea how to manually repro the original bug.
BUT theoretically, this function should never throw. So lets just switch this to a `LOG_IF_FAILED`, and hope that this goes away?
* [x] Fixes#10211?
* [x] built & ran manually.
Unclear if this can get cherry-picked trivially to 1.8. Code's pretty trivial though so if we need another PR for that, it can be arranged.
Stop startup crash by logging when monarch fails to register inbound connections, but still crash when COM attempted to start us
## References
- See also #10243
## PR Checklist
* [x] Closes#10233
* [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
- This should stop the crash on launch until we can get the internal teams to resolve the catalog issue
- I left the COM -Embedding start fail fast though so it won't take forever to time out (as default timeout is 3-5 minutes). I will change that if it becomes necessary.
## Validation Steps Performed
- I basically have to guess at this one based on the crash dump and Watson logs because it happens sporadically when the platform messes up on us.
ConptyConnection has two different failure modes:
1. We failed to initialize the pseudoconsole or create the process
2. The process exited with an error code.
Until this commit, they were treated the same way: closeOnExit=always
would force the pane/tab to be destroyed. This was very bad in case 1,
where we would display a (possibly useful) error message and then
immediately close the window.
This was made even worse by the change in #10045. We removed
startingDirectory validation and promoted it to an error message (so
that we could eventually let the connection handle startingDirectory in
its own way.) This of course revealed that a number of users had set
invalid starting directories… and those users included some who set
closeOnExit to always. Boom: instant "terminal opens and crashes"¹
In this commit, we introduce detection for a connection that fails
before it's been established. When that happens, we will ignore the
user's closeOnExit mode.
¹ It only looks like a crash; it's actually _technically_ functioning
properly.
Closes#10225.
Prevent crashes in Settings UI launch on OS versions before package management extensions
## PR Checklist
* [x] Closes#10106
* [x] I work here
* [x] Manual tests passed.
## Detailed Description of the Pull Request / Additional comments
- On older OS versions like 18363, some of the COM interfaces we use to look up information from the OS application package management catalog (to find default terminals) are unavailable. This returns `E_NOINTERFACE`. This then ends up returning an empty list of items and null as a selected item.
- I had intended for that to not return that particular error all the way up and just log it because the console and terminal lookup functions always return at least one element: the one representing the `conhost.exe` that is already on the machine.
- I have changed the "default packages" lookup to log instead of return failures like E_NOINTERFACE such that it can continue processing and make the "package" of the hardcoded `conhost.exe` default no matter what. (It will still return an error if there are somehow 0 packages because that code changed or some other catastrophic event happened...)
- I have also changed the Model to have a nulled DefaultTerminal model object (as all winrt objects are nullable) instead of using an optional. I did this because XAML is perfectly happy receiving a `nullptr` for a selected item and will just not select anything. By contrast, if it has an exception occur... it will just bubble that out and crash.
## Validation Steps Performed
- Simulated no items returned from list and nullptr returned to XAML on Current() method of Model. Validated XAML will happily select no item from list (and is fine with an empty list of items... that is it doesn't crash).
- Simulated downlevel OS returning package management errors in lookup catalog functions after the hardcoded default is added to the list. Ensured that this error is only logged, the remainder of the package identification functions make the hardcoded default package, and it is presented as your one and only option in the XAML.
Summon the listening window when it receives an inbound connection
## PR Checklist
* [x] Closes#9460
* [x] I work here.
* [x] Manual test.
## Detailed Description of the Pull Request / Additional comments
- We cannot just send our window to foreground by simply calling user32 on the window handle. But fortunately, the remoting behavior already has a summon window function with a workaround for the Quake functionality.
- This bubbles up an event from the TerminalApp's Page to the WindowsTerminal's Apphost so it can call the same window summoning behavior in IslandWindow as is triggered when the Monarch dictates this out of the Microsoft.Terminal.Remoting project.
## Validation Steps Performed
- Opened the Terminal with it registered as DefTerm. Activated some other windows to the foreground. Start > Run > Cmd. Tab connects and opens in existing Terminal and it is brought to foreground.
- With no running Terminal and registered as DefTerm, do Start > Run > Cmd. New Terminal is spawned and it is brought to foreground
## Summary of the Pull Request
VS16.10 and later contain two regressions:
* Marking the use of `pshpack*.h` in system headers with C4103
* The newly included, builtin `AssemblyReference.xaml` is missing the `AssemblyReferences` project capability
## PR Checklist
* [x] I work here
## Validation Steps Performed
Built the project with VS16.10 and VS17.0.
Correct Default Application Selector styles for high contrast and to change with OS theme dark/light toggle
## References
- https://docs.microsoft.com/windows/uwp/design/controls-and-patterns/xaml-theme-resources
## PR Checklist
* [x] Closes#10181
* [x] I work here
* [x] Manual tests passed
## Detailed Description of the Pull Request / Additional comments
1. If I'm going to override colors, I need to define styles in a resource dictionary with Light, Dark, and HighContrast variants so it can be appropriate for each of those.
2. For HighContrast, I need to not mess with text colors and let them follow the default settings.
3. For using System Brushes, I need to use a `ThemeResource` binding not a `StaticResource` binding. The former lets it change when you flip the OS toggle Light/Dark. The latter is stuck to whatever it was when the page loaded.
## Validation Steps Performed
- Loaded in light mode. Flipped to dark. Watched it change live. Checked both unselected and rollover/selected to ensure it was fine.
- Loaded in dark mode. Flipped to light. Watched it change live. Checked both unselected and rollover/selected to ensure it was fine.
- Flipped to HC. Watched it change live. Confirmed that unselected is black/white contrast and the roll over has the cyan/black. (No longer uses special second-line brush for HC, matches the controls I modeled this one on from OS Settings).
<!-- 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
Adds a new bellStyle called `window`. When `window` is set and a BEL is emitted, we flash the pane that emitted it.
Additionally, changes bellStyle in the SUI to a list of checkboxes instead of radio buttons, to match bellStyle being a flag-enum. Deprecates 'BellStyle::Visual' in the schema, but still allows it to be set in the json (it maps to `Window | Taskbar`)
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#6700
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
GIF in Teams
[Defapp] Use real HPCON for PTY management; Have Monarch always listen for connections
## PR Checklist
* [x] Closes#9464
* [x] Related to #9475 - incomplete fix
* [x] I work here.
* [x] Manual test
## Detailed Description of the Pull Request / Additional comments
- Sometimes peasants can't manage to accept a connection appropriately because I wrote defterm before @zadjii-msft's monarch/peasant architecture. The simple solution here is to just make the monarch always be listening for inbound connections. Then COM won't start a peasant with -Embedding just to ask the monarch where it should go. It'll just join the active window. I didn't close 9475 because it should follow monarch policies on which window to join... and it doesn't yet.
- A lot of interesting things are happening because this didn't have a real HPCON. So I passed through the remaining handles (and re-GUID-ed the interface) that made it possible for me to pack the right process handles and such into an HPCON on the inbound connection and monitor that like any other ConptyConnection. This should resolve some of the process exit behaviors and signal channel things like resizing.
Added trace to conhost to instrument buffers that are cooked prior to being passed to the console.
* [x] I've discussed this with core contributors already (internal)
VALIDATION
- Ensured trace is correctly logged in ETL (via TraceLog)
## Summary of the Pull Request
This is a redux of #8882.
From the original:
> This is really similar to what we're doing with the `CommandPalette`. We're adding a ~~Preview~~`KeyDown` handler to the SUI `MainPage`, that connects to `TerminalPage::_HandleKey`. That allows the SUI a chance to search the keymap to dispatch actions for keybindings, similar to how the command palette does it.
>
> This also means it's now possible for the SUI to invoke _all_ the actions available to the Terminal. This includes the ones like `IncreaseFontSize`, which require a _Terminal_ to actually do something. So we have to make sure all the calls to `_GetActiveControl` actually check that the result is non-null before using it.
>
> A bunch of the actions do nothing now from a SUI tab, others behave _weird_. Like "Rename tab" / "Open Tab Renamer" do nothing. "Duplicate Tab" again does nothing - we try making a new settings tab, which just focuses the settings tab again. "Copy text" definitely does nothing, same with paste.
I don't know why I thought this wouldn't work. I thought we'd have to do this in `PreviewKeyDown` or something, which led to [weirdness](https://github.com/microsoft/terminal/pull/8882#issuecomment-767088554). Turns out, we don't need it to be in `PreviewKeyDown`. It can just be in the SUI's `KeyDown`.
## References
* Original: #8882
* Workaround was in #8885
## PR Checklist
* [x] Closes#8767
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Detailed Description of the Pull Request / Additional comments
The special case handler from #8885 is no longer needed
## Validation Steps Performed
* Switching tabs with Ctrl+Tab works
* Command palette works
* fullscreen, focus mode works
* close window works
* copy paste on Ctrl+C/V works, even when bound
* Select all text in textboxes works
* tab navigation through UI elements works
Each mouse-down event's time and position is now stored, and if we
process a left-mouse-down event at the same position as the previous one
and within the double click time we set the double click flag.
Also adds a case statement to `_UpdateSGRMouseButtonState` so that we
send hover events instead of ignoring them.
Note: The 'right-click menu in far manager shows up at the wrong
location' bug still exists with this, as it seems to use the cursor
position as told by user32.
Related to #376
## Validation Steps Performed
Double click in far manager works, hover in far manager works (hovering
over items in the right-click menu correctly highlights them)
Went for option 2 proposed here:
https://github.com/microsoft/terminal/issues/10140#issuecomment-845193132.
Disabling back space in the nested entry didn't felt as the nicest
solution. Instead now all state that keeps track of nested commands is
cleared when switching beteen modes.
## Validation Steps Performed
- Validated the specified issue is fixed by this change:. now after
entering a sub command and hitting backspace the palette no longer
shows the sub command item (here `< Select color scheme...` ).
- Validated that switching between all modes (command line, actions, tab
search & tab switch) still work as expected.
- Validated as well that all modes still work as expected.
Didn't add unit tests, but happy to try that out if this would be
required.
Closes#10140
