Cleans up a ton of competing and outdated sources from our NuGet.Config to improve reliability and maintainability.
## PR Checklist
* [x] Closes an overdue-to-clean mess.
* [x] I work here.
* [x] Tests covered below.
* [x] I've discussed this with @DHowett already.
## Validation Steps Performed
- [x] - NuGet restored everything I could get my hands on (all `packages.config`) in our project before and after the change.
- [x] - The build and tests still run fine. (PR automation should check this one)
A part of the #8415.
Includes:
* Moving `TabSwitcherMode` related decisions into `CommandPalette`
(simplifying the logic of `TerminalPage::SelectNextTab`)
* Fix a bug where the index of first tab switch is incorrect
(since bindings are not updated)
* Removing redundant `CommandPalette` updates
* Preparations for tabs binding
Removes the visibility hack in `UpdateSettings` where we were hiding
Profile menu items instead of removing them. This hack was removed using
`ReplaceAll`. For an unknown reason, calling `Remove()` would result in
an out-of-bounds error in XAML code.
The "Discard" button would improperly refresh the Settings UI. Both of
the bugs were caused by holding a reference to a hidden menu item then
trying to set the `SelectedItem` to that menu item.
Additionally, 9283375 adds a check for the selected item in
`SettingsNav_ItemInvoked()`. This prevents navigation to an already
selected item. This was the heuristic used by the XAML Controls Gallery.
References #6800 - Settings UI Epic
## Validation Steps Performed
(Repeated for each menu item)
1. Select the menu item
2. click "Discard changes"
3. Verify navigated to same page
Also performed repro steps for #8747 and #8748.
Closes#8747Closes#8748
This PR adds a sample monarch/peasant application. This is a type of
application where a single "Monarch" can coordinate the actions of multiple
other "Peasant" processes, as described by the specs in #7240 and #8135.
This project is intended to be a standalone sample of how the architecture would
work, without involving the entirety of the Windows Terminal build. Eventually,
this architecture will be incorporated into `wt.exe` itself, to enable scenarios
like:
* Run `wt` in the current window (#4472)
* Single Instance Mode (#2227)
For an example of this sample running, see the below GIF:
This sample operates largely by printing to the console, to help the reader
understand how it's working through its logic.
I'm doing this mostly so we can have a _committed_ sample of this type of application, kinda like how VtPipeTerm is a sample ConPTY application. It's a lot easier to understand (& build on) when there aren't any window shenanigans, settings loading, Island instantiation, or anything else that the whole of `WindowsTerminal.exe` needs
* [x] I work here
* [x] This is sample code, so I'm not shipping tests for it.
* [x] Go see the doc over in #8135
This PR Makes sure that after you save the settings, we stay on the same part of the profiles pivot. We do this by having a singleton `ProfilesNavigationState`, a bit like the color scheme one in #8799. Hence why this PR is targeting the other.
## PR Checklist
* [x] I work here
* [x] Tested manually
* [x] Fixes the first point in #8769
## Summary of the Pull Request
This PR fixes two of the components of #8765.
> * [ ] Edit a color scheme -> Hit 'apply' -> the selected color scheme resets to the first color scheme in the list (instead of the one just edited)
This was fixed by storing the navigation state as a singleton in MainPage, and having the color schemes page update the selected scheme on that singleton. That way, a subsequent navigation to the schemes page could re-use the existing state.
> * [ ] The buttons turn gray on rollover covering up what color I'm looking at (I have dark mode)
This one was tricky. We're binding the resource for this button, to the color the button is bound to. We're also running a converter on that color, as to change the alpha slightly. This allows us to still have visual feedback on pointerover, without obscuring the color entirely.
## PR Checklist
* [x] I work here
* [x] Tested manually
`til::details::bitmap<Allocator>` will use `Allocator` for its
`dynamic_bitset`, and it will use a rebound allocator for its run storage.
Allocator should be an allocator type storing `unsigned long long`, the
backing store type for `dynamic_bitset`.
I've introduced a type alias, `til::bitmap`, which papers over the
allocator choice for all existing code. I've also introduced a second
type alias, `til::pmr::bitmap`, which lets a consumer use the C++
polymorphic allocator system.
I chatted with @miniksa about whether to keep the "full" allocator
version in `details` or not. We decided that for the simplicity of the
`til` namespace, we would. If anybody has a compelling reason to use
`til::details::bitmap<Allocator>` directly, we can re-evaluate this
decision.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/issues/2886
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already.
## Detailed Description of the Pull Request / Additional comments
Currently the tab tool tip is the tab's title.
The PR teaches the TabBase to check if there is a switch to tab command
associated with the current tab index,
if so concatenates the the relevant mapping to the too tip.
Of course, prefers user defined bindings to the default ones.
Moved tool tip logic to TabBase so SettingsTab has tooltip as well.
The following code didn't previously work as the assignment operators
didn't return a self reference:
```cpp
auto channel = til::spsc::channel<QueueItem>(100);
auto producer = std::move(channel.first);
channel.first = std::move(producer);
```
## Validation Steps Performed
I've added a basic smoke test for `til::spsc`.
Closes#8695
## Summary of the Pull Request
Two parts:
* Hide the BG image settings when no image is specified
* Add a checkbox for "Use desktop wallpaper". When that's checked, the BG image path input is hidden. Unchecking that box restores the path to what it was before.
## PR Checklist
* [x] Closes#8763
* [x] I work here
## Validation Steps Performed
Tested manually
This is by no means comprehensive. It will be unmarked as draft when it
is more comprehensive.
This pull request adds some tests for resizing a TextBuffer and
reflowing its contents. Each test takes the form of an initial state and
a number of buffers of different sizes. The initial state is used to
seed the first TextBuffer, and the subsequent buffers are only used to
compare.
I manually reimplemented some of the DBCS logic to ensure that the
buffers contain _exactly_ what they're supposed to. I know this is
non-ideal. After some of the CharRow changes in #8446 land, this will
need to be updated.
There's a cool bit of TAEF gore in here: the IDataSource. An IDataSource
allows us to programmatically return test cases. It's a code-only
version of its support for parameterized tests of the form `Data:x = {0,
1, 2}` .
The only downsides are...
1. It looks like COM (it is not using COM under the hood, just the COM
ABI)
2. Property values must be returned as strings.
To best support rich test types, I used IDataSource to produce _a lit of
array indices_ and nothing more. The test is run once for array member,
and it is the test's responsibility to look up the object to which that
index refers.
Works great though! Each reflow test is its own unit, and a failure in
an earlier reflow test will not tank a later one.
Procedural solution for https://github.com/microsoft/terminal/issues/756.
Introduces a `startupActions` global setting.
This setting is as string with the same format as actions in command line arguments.
It is used only if command line arguments were not provided
(aka running pure wt.exe).
The setting allows implicit new-tabs.
In the case of invalid syntax we show the warning dialog and ignore the setting.
The documentation PR is here: https://github.com/MicrosoftDocs/terminal/pull/217
<!-- 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 negative value check for when the terminal window is hidden/show in VS
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
[Bug 1265984](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1265984): [Terminal] VS crashes when clicking the hidden terminal tab
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] 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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Manual validation.
<!-- 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 checkbox for 'inherit from parent process' for starting directory
When checked, the textbox and browse button are disabled
If the starting directory is empty, the checkbox is automatically checked
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#8761
* [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
<img width="328" alt="pardir1" src="https://user-images.githubusercontent.com/26824113/104529798-64038980-55bf-11eb-93fd-75e6cf1e2547.png">
<img width="317" alt="pardir2" src="https://user-images.githubusercontent.com/26824113/104529803-66fe7a00-55bf-11eb-89b6-5b35c8ab89b8.png">
Sorts the list of `EnumEntry`s that is used to create combo boxes and
radio buttons in the Settings UI. `INITIALIZE_BINDABLE_ENUM_SETTING`
sorts the list in increasing order of the enum values, whereas
`INITIALIZE_BINDABLE_ENUM_SETTING_REVERSE_ORDER` does so in decreasing
order.
## References
#6800 - Settings UI Epic
I attempted sorting the `IObservableVector<EnumEntry>` using
`std::sort`, but I would get an error in
`winrt::Windows::Foundation::swap` (`C2665`). So instead, I did the
following approach:
- (unchanged) we're converting the `IMap` from EnumMappings into (1) a
map of localized strings and (2) the list for XAML controls
- instead of storing `EnumEntry`s to the `IObservableVector` directly,
store it to a `std::vector`
- sort the vector using `std::sort`
- _now_ initialize the `IObservableVector` using the sorted
`std::vector`
This uses the value of the associated enum to determine a sorting order.
Since we want the "negative" value (i.e. "none" or "hidden") to be last,
I use `EnumEntryComparator` and `EnumEntryReverseComparator` to
determine whether we want increasing or decreasing order respectively.
`INITIALIZE_BINDABLE_ENUM_SETTING_REVERSE_ORDER` is a copy of
`INITIALIZE_BINDABLE_ENUM_SETTING`, except it uses
`EnumEntryReverseComparator` to sort in decreasing order.
Closes#8758
Put some settings below the acrylic & background image settings. Those groups have controls that will become visible when the user enables the setting. If there's other controls below them, then it's less likely that the user has _exactly scrolled to the checkbox_. That means it's more likely that the newly visible controls will be on-screen.
* [x] closes one checkbox in #8764
* [x] I work here
Whenever you'd make a change to anything in the Terminal Control
project, then tried deploying the package, you'd get errors like
"Package contains two files with the same name and different content,
files are `Thing.xbf` and
`.../bin/x64/debug/TSM/TerminalControl/Thing.xbf`". It seems like
`GetPackagingOutputs` was double counting these xbfs as being both from
TerminalControl and also TSM&TSE. So if you'd change TerminalControl,
it'd change the xbf files, but not the ones in TSM/TSE, and then
eventually the wapproj would fail to put it all together.
This combination of flags seems to
* make mdmerge work
* make the packaging project work
* make a partial rebuild of TerminalControl followed by a deploy work
I'm hoping that this PR build will confirm that this works in CI as well.
## PR Checklist
* [x] Fixes this minor annoyance I've been having for the past 2 months
* [x] I work here
## Validation Steps Performed
Validated locally on VS 16.8.3. Sure to break by 16.9 🙃.
## Summary of the Pull Request
I forgot to reset the `--size` argument to `split-pane` when I added it. This PR fixes that, and adds a test so I don't regress it again.
## References
* Missed in #8543
## PR Checklist
* [x] I work here
* [x] Tests added/passed
When we display a dialog to warn the user that they are doing a
multi-line paste, we show the clipboard contents
The contents are shown in a scroll viewer with a fixed maximum height.
Closes#7997
Store the order of the bindings and upon lookup prefer the binding
that was added last.
The defaults will always "loose" to user overrides.
Closes#2991
## Summary of the Pull Request
Adds support for the `move-focus` subcommand to `wt.exe`. This subcommand works _exactly_ like `moveFocus(up|down|left|right)`.
## References
* Will surely conflict with #8183
* Is goodness even in the world where #5464 exists
## PR Checklist
* [x] Closes#6580
* [x] I work here
* [x] Tests added/passed
* [x] Docs PR: MicrosoftDocs/terminal#209
## Detailed Description of the Pull Request / Additional comments
Bear with me, I wrote this before paternity leave, so code might be a bit stale.
Oddly, after startup, this _does not_ leave the focus on the pane you moved to. If you `move-focus` during startup, at the end of startup, we'll still focus a _random_ pane. This is because the terminal still auto-focus a TermControl when it's done with layout. While we'll maintain the active control just fine during the startup, at the end of startup, all the controls will complete layout in a random order.
This is no different than the startup right now. `wt sp ; sp ; sp` will focus a random pane at the end. This is left for a future someone to fix
This is also subject to #2398 / #4692. Moving in a direction isn't _totally_ reliable currently. `focus-pane -t ID` will certainly be more reliable, but this will work in the meantime?
## Validation Steps Performed
Opened probably 100 terminals, confirmed that the layout was always correct. Final focused pane was random, but the layout was right.
## Summary of the Pull Request
This is a spec for "pane navigation", as we've already got a bit of an implementation in #8183. We've also had a heated discussion in Teams, and I wanted to capture a bit of that in a more formal doc. I suppose that "informal Teams chat" didn't work out in the end 😆.
Also, this is @PankajBhojwani's feature so I'm gonna let him drive. I mostly wrote this to test out a new spec template.
After discussion, we landed on proposal D, with a minor change of `last` to `prev`. This is how it was in #8183 before I started meddling 😝
## PR Checklist
* [x] spec for #2871
* [x] I work here
## Detailed Description of the Pull Request / Additional comments
This is not my best spec ever - again, mostly just trying to spawn discussion, and prototype the new spec template.
<!-- 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
This PR implement the OSC 9;9
|Sequence|Descriptoin|
| :------------- | :----------: |
|ESC ] 9 ; 9 ; “cwd” ST | Inform ConEmu about shell current working directory.|
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#8214
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [X] Closes#8166
* [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
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
- Detect `\r` when warning about multi line paste
- Translate `\n` to `\r` on paste
## PR Checklist
* [x] Closes#8601
* [x] Closes#5821
## Validation Steps Performed
Manual testing
Basically, just impose a height on both the renamer box and the overall
tab header control. However, to ensure that the text in the tab renamer
box does not get clipped by its own border, we also need to set its font
size, which is slightly smaller than it was before but it _is_ the same
as the text block that it is trying to rename so I'd say its more
consistent now.
We also improve the tab renamer box so that it scrolls as more text is
added instead of getting truncated (when the tabWidthMode is anything
other than titleLength). When the tabWidthMode _is_ set to titleLength,
the renamer box can increase in length much more (see GIFs below).
Closes#8519
Following up https://github.com/microsoft/terminal/pull/8586 by @Hegunumo,
fully remove the command dispatching logic from Command Palette.
Currently Command Palette might dispatch command in Tab Switcher mode.
This leads to several inconsistencies:
* Only the commands with the same key modifier as an ATS anchor will be issued
* This command will not close the TabSwitcher
(while commands issued from TerminalPage do).
Implementation details:
* Pass KeyMapping rather than binding to CommandPalette
* Use this mapping inside previewKeyDownHandler of ATS to detect
if previous tab or next tab bindings were engaged.
No need to handle Ctrl+Tab explicitly anymore -
it is handled as any other binding.
* Cleanup the logic in TerminalPage::_SelectNextTab
that checks if CommandPalette is visible.
It is not required anymore, as visible palette would intercept the call.
* Remove dependency of TerminalPage on AppLogic
that was introduced lately .
Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will
be responsible for all the Monarch/Peasant work that's been described in
#7240 & #8135.
This PR does _not_ implement the Monarch/Peasant architecture in any
significant way. The goal of this PR is to just to establish the project
layout, and the most basic connections. This should make reviewing the
actual meat of the implementation (in a later PR) easier. It will also
give us the opportunity to include some of the basic weird things we're
doing (with `CoRegisterClass`) in the Terminal _now_, and get them
selfhosted, before building on them too much.
This PR does have windows registering the `Monarch` class with COM. When
windows are created, they'll as the Monarch if they should create a new
window or not. In this PR, the Monarch will always reply "yes, please
make a new window".
Similar to other projects in our solution, we're adding 3 projects here:
* `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a
static lib.
* `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL,
for use in `WindowsTerminal.exe`.
* `Remoting.UnitTests.dll`: A unit test dll that links with the static
lib.
There are plenty of TODOs scattered about the code. Clearly, most of
this isn't implemented yet, but I do have more WIP branches. I'm using
[`projects/5`](https://github.com/microsoft/terminal/projects/5) as my
notation for TODOs that are too small for an issue, but are part of the
whole Process Model 2.0 work.
## References
* #5000 - this is the process model megathread
* #7240 - The process model 2.0 spec.
* #8135 - the window management spec. (please review me, I have 0/3
signoffs even after the discussion we had 😢)
* #8171 - the Monarch/peasant sample. (please review me, I have 1/2)
## PR Checklist
* [x] Closes nothing, this is just infrastructure
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
In dark mode (and high contrast mode), color animation of title bar
button uses wrong color. Cause of this issue is using invalid data in
`ColorAnimation`. I fixed this bug by changing `ColorAnimation` value
in XAML layout file.
According to a [forum post], `To` value of `ColorAnimation` must be
frozen. But original source code uses "color binding" which makes this
value dynamic. As a result, the value set by default is always used,
that means, light mode.
So I added new resource named `CaptionButtonStrokeColor` and
`CaptionButtonBackgroundColor` which has static color value.
In light mode and dark mode, I set `SystemBaseHighColor` in the color
resource. `SystemBaseHighColor` is the same as
`SystemControlForegroundBaseHighBrush.Color` which is originally used in
animation.
The background color animation happened to work correctly because its
value is the same between light mode and dark mode. But I also fixed
background color animation.
## Validation Steps Performed
There is no need to add new test with this fix.
- I changed the `theme` value in `settings.json` and confirmed that the
correct color values were used.
- I confirmed that it works correctly even if the Windows theme is
changed.
[forum post]: https://social.msdn.microsoft.com/Forums/vstudio/en-US/027c364f-5d75-424f-aafd-7fb76b10b676/templatebinding-on-storyboard?forum=wpfCloses#7314
This commit makes "Open in Windows Terminal" Context menu work again for
directory background even on system that OS fix is not applied.
This is a fallback solution to OS fixes mentioned in #6414.
While OS fix is on its way, we need a fallback that works on existing OS
versions.
The approach to this is: when no item is selected (nullptr for
IShellItemArray*), we use shell api to query the path of current active
Explorer window. A special case is handled for Windows Desktop. Once
we are able to obtain the path, we launch Windows Terminal with it.
## Validation Steps Performed
1. Right click on desktop to bring up the Context menu, pick "Open in
Windows Terminal", verify that a terminal is opened with correct
initial path.
2. Open a few File Explorer windows, pick any window, navigate to a
folder, click on "Background" to bring up the context menu, click
"Open in Windows Terminal" verify that a terminal is opened with
correct initial path.
Closes#6414
## References
* Commit f273aa679d4d9fb516678fc7ed5fc6495a8e8532 from os repository.
## PR Checklist
* [x] Closes#7650
* [x] I work here.
* [x] Tests passed
## Detailed Description of the Pull Request / Additional comments
* We found and fixed this in November 2017, but I fumbled the replication and accidentally overwrote the commit. This digs it up from history and puts it back in our code.
* When the shortcut file cannot be read for whatever reason, we are setting the hotkey value to uninitialized data as we never initialize several members on the stack in this function. It just so happens that the one in the `dwHotkey` field is commonly `0x4c` or the letter `L` which is then sent into the window procedure to tell the OS to capture it as a global hotkey and foreground the `conhost.exe` that was started. We should realize the load failure and not set any hotkey at all and we should initialize the stack variables. This does both.
## Validation Steps Performed
* [x] Manual scenario running LNK file that cannot be loaded from customer report (make LNK to cmd.exe, make it inaccessible to conhost so it can't load/read it.)
* [x] Manual scenario with `mklink`'d link that makes the shortcut parser attempt to load (and fail because it isn't a LNK at all from #7650)
Converts the poly text out string and width buffers to use a memory pool since we free/alloc those every frame and are just going to reuse them over and over.
## PR Checklist
* [x] Supports #3075
* [x] I work here.
* [x] Profiled memory before/after. Tested manually with `big.txt`.
## Detailed Description of the Pull Request / Additional comments
- Sets up a PMR memory pool for the GDI Engine. It tends to alloc and free a bunch of little buffers during painting frames. The pool will likely hold onto that memory frame over frame, but we'd just be using it again and again and again anyway. So this way we avoid all the system memory allocator locks and syscalls.
## Validation Steps Performed
- Ran `big.txt` about 10x in the window. Checked WPR/WPA profile output before/after.
Make a few changes to memory usage throughout the application to reduce transient allocations from the `big.txt` test from ~213,000 to ~53,000.
## PR Checklist
* [x] Supports #3075
* [x] I work here.
* [x] Tested manually and WPR'd. Test suite should still pass.
* [x] Am core contributor
## Detailed Description of the Pull Request / Additional comments
Transient allocations are those that are new'd, used, then delete'd. Going back and forth to the system allocator for things we're just going to throw away or use rapidly again is a performance detriment. Not only is it a bunch of time to go ask the system with a syscall, it also hits a whole bunch of locks on the allocators. This PR identifies a few places where we were accidentally allocating and didn't mean to or were allocating and freeing just to turn around and allocate again. I chose other strategies to avoid this.
## Validation Steps Performed
- Ran `big.txt` sample (~6MB file) before and after. Observed heap allocations with WPR.
Performs a number of minor bugfixes related to the Settings UI:
- b5370a1 Dropdown bug:
- the dropdown would display the keybinding for the first
`openSettings` found. So it would accidentally present and bind the
one for the Settings UI.
- 91eb49e autogenerated name for opening Settings UI:
- the Settings UI keybinding would display "open settings file". This
was updated to say "Open Settings UI".
- 1cadbf4 Profile Page navigation crash:
- the selected item off of a MUX navigation view returns a MUX
NavViewItem (as opposed to WUX)
- dd2f3e5 Hookup delete for Profile page navigation:
- missed a spot where we were manually navigating to the Profile
page. So it wasn't hooked up properly
- 9fea6de Properly cast NavViewItem tags
- When we update the NavigationView's menu items, we were casting the
tags to `Model::Profile` instead of `Editor::ProfileViewModel`.
## References
#6800 - Settings UI epic
Fixes the following bug:
> - [ ] JSON change --> crash
> - open SUI --> open JSON --> edit retro effects in JSON --> save file --> cry because the app crashed
## Additional comments
This was a part of some manual testing I performed on the Settings UI.
More intricate bugs are being reported on #6800 and will be fixed in
their own PR.
Fix `TabPaletteItem` to hold only a weak reference to a tab.
This way we guarantee that the refcount of the closed tab
gets to 0 immediately
(and that command palette cannot "raise it from the dead").
While this seems a correct thing to do,
it is still not clear why the `FilteredCommand` itself
(the one holding the `TabPaletteItem`) doesn't get released
until the UI is refreshed.
There is an impact of not registering to PropertyChanged event:
if the tab title changes during Tab Switcher navigation
the Tab Switcher item won't be updated immediately
(the change will apply next time the Tab Switcher is open).
Due to this change we need to make sure that the tabs binding
in https://github.com/microsoft/terminal/pull/8427
doesn't break the title / icon update.
## Validation Steps Performed
* Manual testing
Closes#8651
Fix memory leak that occurs from not dispatching the end of sequences on all actions (since it is buffering up all characters for trace reasons.) Also don't bother storing if no one is listening.
## PR Checklist
- [x] Closes#8283
* [x] Fixes leak found while bumbling around.
* [x] I work here.
## Detailed Description of the Pull Request / Additional comments
- We trace all the things leading up to the Action phase in the VT parser for ETW tracing to make debugging the parser easier, but we made two mistakes.
- At some point, three of the actions (related to print/execute) weren't dispatching the stored up sequence to tracing and not clearing it. So printing/executing in a giant run over and over caused the vector to bloat and bloat and bloat forever.
- We're storing things even when no one is listening. That's a waste.
## Validation Steps Performed
- Watched it grow every time I did `type big.txt` under `taskman.exe`. Then watched it not do that after.
- I did technically WPR it to figure out this was the culprit.
