The original research for a solution all the way back in #11032 contained an
unfortunate flaw. The nearby font loading code was written under the assumption
that Cascadia is missing in the system font collection, leading to our issues.
Adding nearby fonts last into the collection would thus ensure that we use
the system fonts whenever possible, but only have nearby fonts as a fallback.
This didn't work and we figured that we'd have to always prefer loading nearby
fonts over system fonts. #12554 tried to achieve this, but failed to change
the order in which the font set is built. In order to prefer nearby fonts
over system ones, we have to add the system font collection last.
## PR Checklist
* [x] Closes#11648
* [x] I work here
* [x] Tests added/passed
* [x] Embarrassment for my incompetence
## Validation Steps Performed
* Put Jetbrains Mono into the AppX directory of the Debug build
* Jetbrains Mono shows up in the font selector and is useable
Additionally a more complex mini-test was built:
Using FontForge I've cloned arial.ttf and removed all characters except for
the letter "0". Afterwards I've build a custom font collection the same way
we do it in Terminal, extracted a `FontFace` named "Arial" and called
`IDWriteFont::HasCharacter` for the letter "1".
Loading the system font collection first results in `TRUE` and loading it last
results in `FALSE` (since my custom arial.ttf doesn't have the letter "1").
This confirms that we need to load the system font collection last.
(cherry picked from commit eeb8970c6c)
Service-Card-Id: 80641213
Service-Version: 1.12
This is all of course, conjecture. This crash is totally wild and makes no sense at all. But, we're hoping that this fixes it. This should also make calls to the Monarch a little easier.
You may be asking yourself - why aren't I doing this for the Peasant too? Well, because the Peasant simply doesn't crash like the monarch does. I'm not gonna touch something that's not broken _during ask mode_.
References #12774. We can close the bug if it is verified fixed.
(cherry picked from commit b64fd774ce)
Service-Card-Id: 80383092
Service-Version: 1.12
855e136 contains a regression which breaks buffer reflow if wide surrogate
characters are present. This happens because we made use of the
`TextBufferCellIterator` whose increment operator skips 2 cells for wide
characters. This created a "misalignment" in the reflow logic which was written
for cell-wise iteration. This commit fixes the issue, by reverting back to the
previous algorithm without iterators.
Closes#12837
Closes MSFT-38904421
## Validation Steps Performed
* Run ``pwsh -noprofile -command echo "`u{D83D}`u{DE43}"``
* Resizing conhost preserves all contents ✅
* Resizing Windows Terminal doesn't crash it ✅
* Added a test covering this issue ✅
(cherry picked from commit 10b9044120)
Service-Card-Id: 80340089
Service-Version: 1.12
If we delete a scheme, and the next scheme we've loaded is an inbox one
that _can't_ be deleted, then we need to toss focus to something
sensible, rather than letting it fall out to the tab item.
When deleting a scheme and the next scheme _is_ deletable, this isn't an
issue, we'll already correctly focus the Delete button.
125e9c4790 focused the SelectionBackground
button, which is the _previous_ focusable control, rather than the
following one.
However, it seems even more useful for focus to ALWAYS land on the
scheme dropdown box. This forces Narrator to read the name of the newly
selected color scheme, which seemed more useful.
I'm waiting on feedback from a11y team to see if this solution is
acceptable.
* [x] Is for #11971
(cherry picked from commit 866d22e3a1)
Service-Card-Id: 80283574
Service-Version: 1.12
After switching to ControlsV2, it seems that
delay-loading a dialog causes the ContentDialog to be assigned a
Height equal to it's content size. If we DON'T assign the
ContentDialog a Row, I believe it's assigned Row 0 by default. So,
when the dialog gets opened, the dialog seemingly causes a giant
hole to appear in the body of the app.
Assigning all the dialogs to Row 2 (where the rest of the content
is) makes the "hole" appear in the same space as the rest of the
TabContent, fixing the issue.
Note that the actual content in a content dialog gets parented to
the PopupRoot, so it actually always appeared in the correct place, it's
just this weird hole that appeared in Row 0.
* [x] Closes#12775
* See also:
* #12202 was fixed by #12208
* #12447 was fixed by #12517
* [x] Tested manually
* [x] Reverts #12625
* [x] Reverts #12517
(cherry picked from commit c4e5ebf238)
Service-Card-Id: 80266902
Service-Version: 1.12
You'd think that if a key wasn't present in a ThemeDictionary, it'd fall back to the original value. You'd be wrong - if you provide a Light&dark version of a resource, but not the HighContrast version, the resource loader will fall back to the _Light_ value. Of course.
Before (left top), after (right bottom)
Closes MSFT:38264744
(cherry picked from commit 475b38a905)
Service-Card-Id: 80264531
Service-Version: 1.12
This is like, 2-4% of our crashes. Impossible to say for sure, but this _looks_ like it's the root cause. This is just another one of our `HandleCommandlineArgs` buckets, hopefully the last.
* [x] Hopefully should close out MSFT:38542548
* [ ] No I didn't write tests, impossible to test
* [x] it builds
(cherry picked from commit 89bbbb8d6b)
Service-Card-Id: 80261873
Service-Version: 1.12
This is a crazy idea Dustin and I had.
> we can't repro this at will. But we kinda have an idea of where the deref is. We don't know if the small patch (throw, and try again) will fix it. We're sure that the "just fall back to an isolated monarch" will work. I'd almost rather take a build testing the small patch first, to see if that works
> This might seem crazy
> in 1.12, isolated monarch. In 1.13, "small patch". In 1.14, we can wait and see
I can write more details in the morning. It's 5pm here so if we want this today, here it is.
@dhowett double check my velocity flag logic here. Should be always true for Release, and off for Dev, Preview.
* [x] closes#12774
(cherry picked from commit 446f280757)
Service-Card-Id: 80154584
Service-Version: 1.12
On certain builds of Windows, when Terminal is set as the default it
will accumulate an unbounded amount of queued animations while the
screen is off and it is servicing window management for console
applications.
This results in Terminal hanging when left overnight, as it has millions
of animations to process.
The new call into TerminalThemeHelpers will tell our compositor to
automatically complete animations that are scheduled while the screen is
off.
Fixes MSFT-38506980
(cherry picked from commit 8405c7a697)
Service-Card-Id: 80150450
Service-Version: 1.12
Before #12691, the msixbundle version was of the format YYYY.MM.DD.0.
After #12691, it became the same as the build of Terminal it contained.
This caused some trouble for _some_ systems: major version 1 is much,
much smaller than 2022.
Adding 3000 to the major version component, _only for the bundle_, gets
around this. Ugh.
Fixes#12816.
(cherry picked from commit bc6bf15a62)
Service-Card-Id: 80144496
Service-Version: 1.12
Does what it says on the tin. This is maximal BODGE.
`TeachingTip` doesn't provide an `Opened` event.
(https://github.com/microsoft/microsoft-ui-xaml/issues/1607). But we
want to focus the renamer text box when it's opened. We can't do that
immediately, the TextBox technically isn't in the visual tree yet. We
have to wait for it to get added some time after we call IsOpen. How do
we do that reliably? Usually, for this kind of thing, we'd just use a
one-off LayoutUpdated event, as a notification that the TextBox was
added to the tree. HOWEVER:
* The _first_ time this is fired, when the box is _first_ opened,
yeeting focus doesn't work on the first LayoutUpdated. It does work on
the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated
events, and focus on the second.
* On subsequent opens: We only ever get a single LayoutUpdated. Period.
But, you can successfully focus it on that LayoutUpdated.
So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If
we've had at least 2, then we can focus the text box.
We're also not using a ContentDialog for this, because in Xaml Islands a
text box in a ContentDialog won't receive _any_ keypresses. Fun!
## References
* microsoft/microsoft-ui-xaml#1607
* microsoft/microsoft-ui-xaml#6910
* microsoft/microsoft-ui-xaml#3257
* microsoft/terminal#9662
## PR Checklist
* [x] Will close out #12021, but that's an a11y bug that needs secondary
validation
* [x] Closes#11322
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
Tested manually
(cherry picked from commit b57fe85997)
Service-Card-Id: 79978833
Service-Version: 1.12
I also took the opportunity to clean up the WPF stage's artifact rules.
Closes#12786
(cherry picked from commit 0651d92dba)
Service-Card-Id: 79856465
Service-Version: 1.12
If we do not include mp:PhoneIdentity in our AppxManifest, the store
will edit our package and re-sign it for distribution. When that
happens, it creates a divergence: there are now two versions of our
package with the same name and version number, but different contents.
This breaks everything.
**THIS IS LOAD BEARING**
(cherry picked from commit 0bc66abd3b)
## THE WHITE WHALE
This is a fairly naive fix for this bug. It's not terribly performant,
but neither is resize in the first place.
When the buffer gets resized, typically we only copy the text up to the
`MeasureRight` point, the last printable char in the row. Then we'd just
use the last char's attributes to fill the remainder of the row.
Instead, this PR changes how reflow behaves when it gets to the end of
the row. After we finish copying text, then manually walk through the
attributes at the end of the row, and copy them over. This ensures that
cells that just have a colored space in them get copied into the new
buffer as well, and we don't just blat the last character's attributes
into the rest of the row. We'll do a similar thing once we get to the
last printable char in the buffer, copying the remaining attributes.
This could DEFINITELY be more performant. I think this current
implementation walks the attrs _on every cell_, then appends the new
attrs to the new ATTR_ROW. That could be optimized by just using the
actual iterator. The copy after the last printable char bit is also
especially bad in this regard. That could likely be a blind copy - I
just wanted to get this into the world.
Finally, we now copy the final attributes to the correct buffer: the new
one. We used to copy them to the _old_ buffer, which we were about to
destroy.
## Validation
I'll add more gifs in the morning, not enough time to finish spinning a
release Terminal build with this tonight.
Closes#32🎉🎉🎉🎉🎉🎉🎉🎉🎉Closes#12567
(cherry picked from commit 855e1360c0)
In two instances, the help text for the settings UI refers to _transparency_ when we're really talking about _opacity._ This PR changes those occurences to more accurately reflect the setting being described.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#12592
(cherry picked from commit f5882236dc)
`std::basic_string_view::substr` throws an exception if the first argument
(offset) is out of range. If UIA is running, this creates _a lot_ of exceptions
and associated log output. This trivial change takes care of that.
(cherry picked from commit e5b5af5186)
After this commit we only set the default fields of a profile - primarily the
name field - as late as possible, after layering has already completed.
This ensures that we pick up any modifications from fragments.
* [x] Closes#12520
* [x] I work here
* [x] Tests added/passed
* Add a fragment at
`%LocalAppData%\Microsoft\Windows Terminal\Fragments\Fragment\fragment.json`
with
`{"profiles":[{"updates":"{61c54bbd-c2c6-5271-96e7-009a87ff44bf}","name":"NewName"}]}`
* Windows PowerShell profile is created with the name "NewName" in settings.json ✅
(cherry picked from commit ee83081b64)
* Drop engine support for DirectX 9.1
Practically no one has such old hardware anymore and AtlasEngine additionally
drops support for 10.0. The fallback also didn't work properly,
because the `FeatureLevels` array failed to include 9.2 and 9.3.
We'll simply fall back to WARP on all such devices.
* Optimize shaders during compilation
The two new flags increase shader performance sometimes significantly.
* Fix shader feature level flags
D3D feature level 10.0 only support 4.0 and 10.1 only 4.1 shaders.
## PR Checklist
* [x] Closes#12655
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Add `WindowsTerminal.exe` in `dxcpl.exe`
* Add a basic `experimental.pixelShaderPath`
* All forced feature levels between `9_1` and `11_1` render as expected ✅
(cherry picked from commit d5fb7369cb)
This sure is bodgy, but it makes sense. Right now, when we delete a profile, we load in a totally new content for the new profile's settings. That one resets the scroll view and the focus, and now the "delete" button is obviously not focused.
Instead, this PR will manually re-focus the delete button of a profile page when the page is navigated to _because we deleted another profile_.
* [x] This will take care of #11971
(cherry picked from commit 7fdcd6f5b3)
By replacing `IDWriteFontSetBuilder2::AddFontFile` with
`IDWriteFactory5::CreateFontFileReference` and
`IDWriteFontSetBuilder1::AddFontFile` we add nearby
font loading support for Windows 10, build 15021.
This commit also fixes font fallback for AtlasEngine,
which was crashing during testing.
Finally it fixes a bug in DxEngine, where we only created a "nearby" font
collection if we couldn't find the font in the system collection. This doesn't
fix the bug, if the font is locked or broken in the system collection.
This is related to #11648.
* [x] Closes#12420
* [x] I work here
* [x] Tests added/passed
* Build a Debug version of Windows Terminal
* Put Jetbrains Mono into the writeable AppX directory
* Jetbrains Mono is present in the settings UI ✅
* DxEngine works with Jetbrains Mono ✅
* AtlasEngine works with Jetbrains Mono ✅
(cherry picked from commit f84ccad42d)
<!-- 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
Moves baskgroung image update releated code into separate function and adds uri path construction exeption handling.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#11361
* [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
Tried to put garbage as a path. Terminal didn't crashed.
(cherry picked from commit f63159db59)
The store did not like when I uploaded two Windows Terminal packages
built on the same date, because the appxbundle version defaulted to
YYYY.MMDD.something.
There was a risk that using *this* version number will fail because it is
thousands of numbers less than "2022". We'll have to see if the store
rolls it out properly. I cannot find any documentation on how the store
rolls out *bundle* versions (it is very aware of .appx versions...).
A local test with 1.14.72x (Preview) published via the store seems to
have worked.
(cherry picked from commit a5194b0c44)
This commit fixes a stray exception during settings loading,
caused by a failure to obtain the app's extension catalog.
## PR Checklist
* [x] Closes#12305
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
I'm unable to replicate the issue. ❌
However an error log was provided in #12305 with which
the function causing the exception could be determined.
(cherry picked from commit 9c6ec75082)
This change makes Windows Terminal raise a `RaiseNotificationEvent()` ([docs](https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.automation.peers.automationpeer.raisenotificationevent?view=winrt-22000)) for new text output to the buffer.
This is intended to help Narrator identify what new output appears and reduce the workload of diffing the buffer when a `TextChanged` event occurs.
The flow of the event occurs as follows:
- `Terminal::_WriteBuffer()`
- New text is output to the text buffer. Notify the renderer that we have new text (and what that text is).
- `Renderer::TriggerNewTextNotification()`
- Cycle through all the rendering engines and tell them to notify handle the new text output.
- None of the rendering engines _except_ `UiaEngine` has it implemented, so really we're just notifying UIA.
- `UiaEngine::NotifyNewText()`
- Concatenate any new output into a string.
- When we're done painting, tell the notification system to actually notify of new events occurring and clear any stored output text. That way, we're ready for the next renderer frame.
- `InteractivityAutomationPeer::NotifyNewOutput()` --> `TermControlAutomationPeer::NotifyNewOutput`
- NOTE: these are split because of the in-proc and out-of-proc separation of the buffer.
- Actually `RaiseNotificationEvent()` for the new text output.
Additionally, we had to handle the "local echo" problem: when a key is pressed, the character is said twice (once for the keyboard event, and again for the character being written to the buffer). To accomplish this, we did the following:
- `TermControl`:
- here, we already handle keyboard events, so I added a line saying "if we have an automation peer attached, record the keyboard event in the automation peer".
- `TermControlAutomationPeer`:
- just before the notification is dispatched, check if the string of recent keyboard events match the beginning of the string of new output. If that's the case, we can assume that the common prefix was the "local echo".
This is a fairly naive heuristic, but it's been working.
Closes the following ADO bugs:
- https://dev.azure.com/microsoft/OS/_workitems/edit/36506838
- (Probably) https://dev.azure.com/microsoft/OS/_workitems/edit/38011453
- [x] Base case: "echo hello"
- [x] Partial line change
- [x] Scrolling (should be unaffected)
- [x] Large output
- [x] "local echo": keyboard events read input character twice
(cherry picked from commit f9be1720bd)
This removes one source of potential integer overflows from the Viewport class.
Other parts were left untouched, as this entire class of overflow issues gets
fixed all at once, as soon as we replace COORD with til::coord (etc.).
* [x] Closes#5271
* [x] I work here
* [x] Tests added/passed
* Call `ScrollConsoleScreenBufferW` with out of bounds coordinates
* Doesn't crash ✅
(cherry picked from commit a4a6dfcc8d)
This fixes a pair of inbox bugs, hopefully.
* MSFT:35731327
* There's a small window where a peasant is being created when a monarch is exiting. When that happens, the new peasant will try to tell itself (the new monarch) when the peasant was last activated, but because the window hasn't actually finished instantiating, the peasant doesn't yet have a LastActivatedArgs to tell the monarch about.
* MSFT:32518679 (ARM version) / MSFT:32279047 (AMD64 version)
* This one's tricky. Not totally sure this is the fix, bug assuming my hypothesis is correct, this should fix it. Regardless, this does fix a bug that was in the code.
* If the king dies right as another window is starting, right while the new window is starting to ProposeCommandline to the monarch, the monarch could die. If it does, the new window just explodes too. Not what you want.
Vaguely tested the second bug manually, by setting breakpoints in the monarch, starting a defterm, then exiting the monarch while the handoff was in process. That now creates a new window, so that's at least something. `RemotingTests::TestProposeCommandlineWithDeadMonarch` was the closest I could get to testing that.
The first bug only got an eye check. Not sure how to repro, but I figured yeet and hopefully we get it.
* [x] Closes#12624
(cherry picked from commit f507d9f491)
Somehow, the controls v2 update caused an issue where if you as much as _load_ a content dialog when there's already one open, we get holes in the terminal window (#12447)
This commit introduces logic to `TerminalPage` to check whether there is a content dialog open before we try to load another one.
* [x] Closes#12447
* [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
Can no longer repro #12447
## Summary of the Pull Request
This makes it so that the settings.json backups are no longer created when the user saves their settings via the Settings UI.
Closes#11703
(cherry picked from commit 91f5648b5e)
"Summon" was translated as a synonym for "citation" in Spanish instead
of treating it as a RPG-related word. "Show/Hide" will hopefully
allow an improved automatic translation in the future.
Closes#10691
(cherry picked from commit f217f6dc33)
## Summary of the Pull Request
Fixes RTF generation for text with Unicode characters.
## PR Checklist
* [x] Closes#12379
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
Added some unit tests.
Ran the following in PowerShell and copied the emitted text into WordPad.
```pwsh
echo "This is some Ascii \ {}`nLow code units: á é í ó ú `u{2b81} `u{2b82}`nHigh code units: `u{a7b5} `u{a7b7}`nSurrogates: `u{1f366} `u{1f47e} `u{1f440}"
```
(cherry picked from commit 00113e3e48)
This has been a saga.
Basically, any resources in `App.xaml` aren't going to be able to reference other theme-aware resources. We can't change the theme of the app at runtime, only elements within the app. So we can't use `ApplicationPageBackgroundThemeBrush` in app.xaml, because it will ALWAYS be evaluated as the OS theme version of that brush.
* regressed in #12326
* See also #10864
* #3917 CANNOT be fixed in the same way. We're lucky here that the TabView uses a `{ThemeResource TabViewBackground}` in markup to set the bg. We're not similarly lucky with the Pane one.
* [x] closes#12356
* [x] Tested manually. You can confirm, my eyes are bleeding from the OS-wide light mode
* use `FontFamily="{ThemeResource SymbolThemeFontFamily}"` where possible, in XAML
* use `FontFamily{ L"Segoe Fluent Icons, Segoe MDL2 Assets" }` in codebehind
Basically just a simple string replace.
* [x] This was a bullet point in #11353
* [x] Confirmed manually on my win10 PC
* see also #12438
Actually, this is the last bullet in #11353, so I'm gonna say closes#11353.
Screenshots below.
The focus box around the color schemes combo box was getting cut off, this change adds a small margin to the stackpanel to allow space for the focus box
## PR Checklist
* [x] Closes#12328
Segoe Fluent isn't available on Windows 10, and doesn't stealthily ship with WinUI. So if we manually set the font family to `"Segoe Fluent Icons"`, then that will just display boxes in Win10.
This instead uses the resource `"{ThemeResource SymbolThemeFontFamily}"` which will gracefully fall back on Win10.
See:
* https://github.com/microsoft/microsoft-ui-xaml/issues/3745, which inspired this solution.
Guess what! The backgound image icons were also manually specifying this font, so they had to get updated too. I couldn't find any other `Segoe Fluent` references in the code.
* [x] Closes#12350
* [x] Checked Windows 11 locally
* [x] Checked Win10 (screenshots incoming from other machine)
With the recent change to allow text boxes to be bigger, the `Browse` button that some of them have was getting cut off when the window was too narrow. This change puts the `Browse` button below the text box instead of next to it to prevent this issue.
## PR Checklist
* [x] Closes#12335
## Summary of the Pull Request
Reducing the `MinWidth` of a toggle switch means it no longer needs a negative margin to align it correctly
## 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
## Validation Steps Performed
Setting a different language no longer causes the toggle switch to fall out of the expander
## Summary of the Pull Request
We no longer do anything when the rightmost breadcrumb is invoked
## PR Checklist
* [x] Closes#12325
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
Tested manually, cannot repro #12325 anymore
## Summary of the Pull Request
Adds some polish around the navigators in the profile page (i.e. "appearance" and "advanced" button) by doing the following:
- use the localized resources for the pivot on the navigators
- simplify the navigators to be buttons instead of toggle buttons
Doing so has Narrator identify these as buttons rather than toggle buttons. So now Narrator won't say that the button is "off", which just makes more sense.
## Validation Steps Performed
✅ Narrator says "Advanced button" or "Appearance button" on the navigator
✅ The navigators look the same as before
- The add new profile page now uses a dropdown rather than radio buttons
- Subheaders, breadcrumb bar, buttons etc are now all centralized when the window is maximized (so they all align with the expanders now)
- We no longer override the titlebar colors and instead use the xaml defaults (these still aren't great but at least we will get the fix automatically when it happens upstream)
- Breadcrumb bar no longer has a negative margin, so there's no weird overlap that happens when the window becomes small
- The number boxes for launch size and font size now use the `Inline` placement mode rather than compact, allowing modification to the number with fewer clicks
- Textboxes now have a greater max width so they can occupy more space in the expander if needed
## Summary of the Pull Request
Fix various things from the recent SUI changes
- The Appearance/Advanced toggle buttons now have a max width
- We don't need `Profiles.cpp` anymore
- The `Elevate` setting is now back in the SUI
- There is no longer an alignment difference between non-expander settings and expander settings
- Expander settings no longer require hitting `Tab` twice to get to them
<!-- 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
**Note: This PR targets #11720**
Replaces our old pivot-style settings UI with a breadcrumb bar style, as per the windows 11 style guidelines. This required splitting `Profiles.xaml` into 3 separate files, `Profiles_Base.xaml` for general settings, `Profiles_Appearance.xaml` for appearance settings, `Profiles_Advanced.xaml` for advanced settings
The header in the navigation view is now a [BreadcrumbBar](https://docs.microsoft.com/en-us/windows/apps/design/controls/breadcrumbbar), which can be used to navigate back to `Profiles_Base` after moving into the advanced or appearance page (see GIF below)
<!-- Please review the items on the PR checklist before submitting-->
* [ ] 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
This fixes a bug where several settings would not show the reset button. The root cause of this issue is two fold:
1. Hooking up `CurrentXXX`
- `GETSET_BINDABLE_ENUM_SETTING` was hooked up to the **settings** model profile object instead of the **view** model profile object. Since the settings model has no `PropertyChanged` system, any changes were directly being applied to the setting, but not notifying the view model (and thus, the view, by extension) to update themselves.
- This fix required me to slightly modify the macro. Rather than using two parameters (object and function name), I used one parameter (path to getter/setter).
2. Responding to the `PropertyChanged` notifications
- Now that we're actually dispatching the `PropertyChanged` notifications, we need to actually respond to them. This behavior was defined in `Profiles::OnNavigatedTo()` in the `PropertyChanged()` handler. Funny enough, that code was still there, it just didn't do anything because it was trying to notify that `Profiles::CurrentXXX` changed. This is invalid because `CurrentXXX` got moved to `ProfileViewModel`.
- The fix here was pretty easy. Just move the property changed handler to `ProfileViewModel`'s `PropertyChanged` handler that is defined in the ctor.
Bug introduced in #11877✅ Profile termination behavior
✅ Bell notification style
✅ Text antialiasing
✅ Scrollbar visibility
Updates our SUI to follow the windows 11 style guidelines. Includes updating our setting containers to follow the 'expander' style.
* [x] Closes#10631
* [x] Closes#9978
* [x] Closes#9595
* [x] Closes#11231
* [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
Cleans up `ProfileViewModel`, `Profiles`, and `ProfilePageNavigationState` to move all of the view model responsibilities over to `ProfileViewModel`. We don't actually store the `ProfilePageNavigationState` anymore. We only use it as a way to transfer information to the new page.
- I pulled out `ProfileViewModel` into its own file to keep things cleaner. It was getting pretty big.
- The font lists are now stored in a static location in `ProfileViewModel`, which means that we can reuse the same list between pages.
- the profile pivot was also moved to the `ProfileViewModel` and stored as a static value.
✅ pivot behavior is the same
✅ font list is still populated
## Summary of the Pull Request
Prevents a crash that could occur when invoking `wt C:\`
## PR Checklist
* [x] Closes#12535
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Detailed Description of the Pull Request / Additional comments
Updates `CascadiaSettings::NormalizeCommandLine()` to check that there are a suitable number of command line arguments to be concatenated together, to prevent accessing an array index in `argv` that doesn't exist.
Also prevents a test flake that could occur in `TerminalSettingsTests::CommandLineToArgvW()`, due to generating an empty command line argument.
## Validation Steps Performed
Added a test, and checked that invoking each of the command lines below behaved as expected:
```
wtd C:\ # Window pops up with [error 2147942405 (0x80070005) when launching `C:\']
wtd C:\Program Files # Window pops up with [error 2147942402 (0x80070002) when launching `C:\Program Files']
wtd cmd # cmd profile pops up
wtd C:\Program Files\Powershell\7\pwsh -WorkingDirectory C:\ # PowerShell profile pops up in C:\
wtd "C:\Program Files\Powershell\7\pwsh" -WorkingDirectory C:\ # PowerShell profile pops up in C:\
wtd . # Window pops up with [error 2147942405 (0x80070005) when launching `.']
```
Fixes two crashes amounting to 14% of our crash burden in Simulated
Selfhost. I can't reproduce this organically, but I was able to do so by
forcing the command palette to be empty.
From MSFT:36797001. Okay so this is only .22% of our crashes, but every little bit helps, right?
Turns out this is also hitting in:
* MSFT:35726322
* MSFT:34662459
and together they're a fairly hot bug.
There's a large class of bugs where we might get a callback to one of our event handlers when we call `app.Close()` in the `AppHost` dtor. This PR adds manual revokers to these events, and makes sure to revoke them BEFORE nulling out the `_window`. That will prevent callbacks during the rest of the dtor, when the `_window` is null.
Four (4) squashed changes, with messages preserved.
Right now, symbol publication happens every time we produce a final
bundle. In the future, we may be producing multiple bundles from the
same pipeline run, and we need to make sure we only do *one* symbol
publication to MSDL.
When we do that, it will be advantageous for us to have just one phase
that source-indexes and publishes all of the symbols.
This removes the trick we pulled in #5661 and saves us ~550kb per arch.
Some of our dependencies still depend on the "app" versions of the
runtime libraries, so we are going to continue shipping the forwarders
in our package. Build rules have been updated to remove the non-Desktop
VCLibs dependency to slim down our package graph.
This is not a problem on Windows 11 -- it looks like it's shipped inbox.
**BREAKING CHANGE**: When launched unpackaged, Terminal now requires the
vcruntime redist to be installed.
common.openconsole.props is a pretty good place to stash the XAML
version since it is included in every project (including the WAP
project (unlike the C++ build props!)).
I've gone ahead and added a "double dependency" on multiple XAML
versions. We'll toggle them with a build flag.
This required some changes in how we download artifacts to make sure
that we could control which version of Windows we were processing in any
individual step.
We're also going to patch the package manifest on the Windows 11 version
so the store targets it more specifically.
On top of the prior three steps, this lets us ship a Windows 11
package that costs only ~15MB on disk. The Windows 10 version, for
comparison, is about 40.
(cherry picked from commit 53a454fbd3)
When the dpi is changed, call `updateFont()` instead of `TriggerFontChange`, this
means that we continue to use the existing font features/axes
Closes#11287
(cherry picked from commit 3b4679431d)
We chose to use the "ContextMenu" resource compartment when we
changed the package name to Terminal in #12264 because it was more
broadly localized than the rest of the application.
It appears as though some platform features have trouble with the
"more qualified" resource paths that #12264 required.
To fix this, we will:
1. Copy all of the ContextMenu localizations into CascadiaPackage's
resource root
2. Switch all manifest resource paths to use resources from the package
root.
Regressed in #12264Closes#12384Closes#12406 (tracked in microsoft/powertoys#16118)
(cherry picked from commit 9501b23ad1)
#12348 introduced an off-by-one bug. While the `NormalizeCommandLine` loop
should exit early when there aren't at least _two_ arguments to be joined,
the final argument-append needs to happen even if just _one_ argument exists.
This commit fixes the issue and introduces changes to additionally monitor
the early loop exit, as well as the call to `ExpandEnvironmentStringsW`.
## PR Checklist
* [x] Closes#12461
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* All `TerminalSettingsTests` tests pass ✅
(cherry picked from commit e06e1314a8)
Now that we've figured out how to publish the public symbols to the official Microsoft download server... we may as well embed the source code linking information inside of them given that it's right here on GitHub. This attempts to run our existing source linking scripts against the public copy of the symbols.
## PR Checklist
* [x] Closes#12443
* [x] I work here
* [x] Tested manually
## Validation Steps Performed
* [x] Build with it: https://dev.azure.com/microsoft/Dart/_build/results?buildId=44930661&view=logs&j=8f802011-b567-5b81-5fa6-bce316c020ce
* [x] Point the debugger at them and see if it can find the sources
* [x] Maybe also look at them in a hex editor or whatnot and validate I can see the source paths pointing at GitHub
(cherry picked from commit 8b9066962d)
Updates this narrator announcement message to include the number of results it found. There are two versions:
* one for a singular result
* one for multiple results.
which should help with loc.
We're trying to get this in with the loc hotfix, so 👀 please
* [x] will take care of the last bit of #7907
verified with narrator locally.
(cherry picked from commit 9ea0c93435)
We're now building a fully provenance, compliance, and security
validated package (vpack) through our Release pipeline. This attaches
the last phase which automates the submission into the Windows product.
It will also automatically trace back the source, commit SHA, and build
to the submission here from the Windows side.
* [x] Automates a manual activity I performed a few times recently
* [x] I work here
* [x] Ran a test of it against `release-1.12` and it worked
(cherry picked from commit 10c963a7db)
Basically, some WSL distros ship fragments that replace the `commandline` with the executable for their distro (`ubuntu.exe`, etc.). We didn't expect that when we changed the `startingDirectory` for them all to `~`.
Unfortunately, `~` is really never a valid path for a process on windows, so those distros would now fail with
```
[error 2147942667 (0x8007010b) when launching `ubuntu1804.exe']
Could not access starting directory "~"
```
If we find that we were unable to mangle `~` into the user's WSL `commandline`, then we will re-evaluate that `startingDirectory` as `%USERPROFILE%`, which is at least something sensible, if albeit not what they wanted.
* regressed in #12315
* [x] Closes#12353
* [x] Tested with a (`ubuntu1804.exe`, `~`) profile - launched successfully, where 1.13 in market fails.
* [x] added tests
This adds some validation in the `UiaTextRange` ctor for the cursor position.
#8730 was caused by creating a `UiaTextRange` at the cursor position when it was in a delayed state (meaning it's purposefully hanging off of the right edge of the buffer). Normally, `Cursor` maintains a flag to keep track of when that occurs, but Windows Terminal isn't maintaining that properly in `Terminal::WriteBuffer`.
The _correct_ approach would be to fix `WriteBuffer` then leverage that flag for validation in `UiaTextRange`. However, messing with `WriteBuffer` is a little too risky for our comfort right now. So we'll do the second half of that by checking if the cursor position is valid. Since the cursor is really only expected to be out of bounds when it's in that delayed state, we get the same result (just maybe a tad slower than simply checking a flag).
Closes#8730
Filed #12440 to track changes in `Terminal::_WriteBuffer` for delayed EOL wrap.
## Validation Steps Performed
While using magnifier, input/delete wrapped text in input buffer.
I have no idea how this is even possible to hit. If this is able to be null, then we failed to load the settings in such a catastrophic way that nothing should work. However, OP's Terminal seemed to have already loaded the settings. By all accounts, doesn't make sense.
Regardless, the code here would crash if this ever is null, so we may as well catch it.
* [x] Closes#12360
* [ ] No way to verify this since it isn't even reproable on OPs machine, but it does have a lot of hits for that failure bucket (!!!)
The previous code had two bugs for:
* paths with more than 1 whitespace
The code joins the argv array by replacing null-word terminators with
whitespace. Unfortunately it always referred to the separator between
`argv[0]` and `argv[1]` for this instead of continuing to join
those between 1 and 2, etc.
* paths sharing a common prefix with another directory
`SearchPathW` returns paths that aren't necessarily paths to files.
A call to `GetFileAttributesW` was added, ensuring we only resolve file paths.
* [x] Closes#12345
* [x] I work here
* [ ] Tests added/passed
* Paths with more than 1 whitespace resolve correctly ✅
* Paths with neighboring directories sharing a common prefix resolve correctly ✅
* Tests added ✅
The `x-generate` statement seems to have fallen apart somewhere and is no longer generating the valid list of languages for display. This hardcodes the list into the manifest to restore it, which is a valid option per the documentation.
We also hardcode the limited subset of languages into the Settings application because the main application supports fewer languages than we have been translated into for the shell extensions for Windows Explorer and Start Menu integration.
## PR Checklist
* [x] Closes#12351
* [x] I work here.
* [x] Manual tests below
## Validation Steps Performed
- [x] Clean built locally with `msbuild.exe openconsole.sln /p:Configuration=Release /p:Platform=x64 /p:WindowsTerminalBranding=Release /t:Terminal\CascadiaPackage /m /bl:log4.binlog` and checked that the `appxmanifest.xml` that popped out the other side contained the same languages that it used to contain.
- [x] Built in the release pipeline
- [x] Installed release and preview branded packages. Changed my machine language to Polish (pl-PL) which is not one of the fully localized languages, but is one of the limited ones. Checked the start menu and right-click menus and saw Polish text for Terminal and Terminal Preview. Checked the Settings page in our app and saw only the limited 14 language list for the application itself.
We have to do this so that the store sees us as one thing ("Windows
Terminal") and the Start menu sees us as another ("Terminal").
The store will reject our package if the value we use for "DisplayName"
here doesn't match the store's "reserved names".
This value is *not used* by the start menu.
(cherry picked from commit e064c15675)
## Summary of the Pull Request
When using a screen reader, the buttons on the "add a new profile" page were being read weirdly:
- "New empty profile" button read as "create new button button"
- "duplicate" button read as "duplicate button button"
It's generally standard to read out the text inside the button, so I did just that by reusing the existing localized resources. This also removes the redundant "button" that is said by the screen reader.
I also removed the unused `AutomationId` and unnecessary `Button.Content` tags.
#11156 can be closed upon validation by the accessibility team.
## Validation Steps Performed
✅ navigate to both buttons using Narrator; make sure it sounds right
(cherry picked from commit 24c5f7bba4)
Since we turned this feature on in windows, and it relies on _lying
about the contents of the registry_, Terminal needs to be in on the
joke.
This will need to be reverted and serviced if we choose not to ship like
this.
Fixes#12308
(cherry picked from commit 457738e388)
I added a condition to exclude some of the NuGet PGO stuff when there was no build mode, but appear to not have propagated any of it in the PGD merge job. This sets it to Optimize here so it'll go through.
## PR Checklist
* [x] Closes#12300
* [x] I work here.
* [x] It blends.
## Validation Steps Performed
* [x] Ran the PGO Instrument Phase
* [x] Ran the PGO Optimize Phase
(cherry picked from commit 469202f462)
Basically, this is the same as #12266, but for the `SearchBoxControl`. Trickily, the ControlCore is the one that knows if there were search results, but the TermControl has to be the one to announce it.
* [x] Will take care of #11973 once a11y team confirms
* [x] Tested manually with Narrator
* [x] Resolves a part of #6319, which I'm repurposing just to displaying the number of results in general.
* See also #3920
(cherry picked from commit fbe0416305)
This adds names to more of our focusable elements. This should be the rest of them that I missed in #11364
* #9990: a11y megathread
* #11155: original version of this
* [x] Should take care of #11996 once confirmed
* [x] I work here
Used Accessibility Insights to verify.
There is one other weird bit. All the expanders that have content below the expander (not inline), show up as focusable, but don't have names. Even when I add names to them. I believe this is due to https://github.com/microsoft/microsoft-ui-xaml/issues/5820, which is fixed in https://github.com/microsoft/microsoft-ui-xaml/pull/6032, in https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.8.0-prerelease.220118001. Unfortunately, we're on a 2.7 prerelease, so we don't have that fix yet. I may see how painful moving to that is, because we're gonna get another a11y ping as soon as 1.13 ships.
I pre-emptively added names to these guys in f7ba158dc, so that the new MUX should just fix this without any thinking on our part.
(cherry picked from commit cf4d47c54d)
I didn't have the tray icon enabled before I suppose, so this never got hit? Anyhow, we need to change where we look for the AppName. Otherwise we crash on launch 😨
* [x] fixes `main`
* [x] I work here
* regressed in #12264
* [x] Tested by: actually running the Terminal with this, it launched
(cherry picked from commit 7150fd8f97)
## Summary of the Pull Request
According to https://github.com/microsoft/microsoft-ui-xaml/issues/1971, `PaneFooter` does not set the `SizeOfSet` or `PositionInSet` properties. However, `FooterMenuItems` does and works for our scenario. So we just replaced `PaneFooter` with `FooterMenuItems`.
Will handle #11154 upon verification from the accessibility team.
## Validation Steps Performed
✅ Verified using Accessibility Insights
✅ "Open Json File" button can still be invoked and keyboard navigated to as expected
(cherry picked from commit 2861b41fd0)
This should be most of the surfaces that we really care about for displaying "Windows Terminal". There's a pile of other references in code, but I couldn't find any other resources that mention it.
I left a lot of the references to Windows Terminal throughout. Seemed like it was fine to keep calling it that in most places, just these localized strings that are going to be displayed in the Shell that should be changed.
Rough compare:
The strings were also moved to the Context Menu resources file, because that's localized into more languages.
@DHowett we may want to spin a full build to make sure this works and I didn't miss anything
* [x] Closes#12091
(cherry picked from commit a66a1c0cf5)
## Summary of the Pull Request
Expands on #9582. If the command palette finds results, the screen reader says "Suggestions available".
Makes the scenario mentioned in #7907 work.
This is sufficient for various reasons:
1. According to the bug report, saying that suggestions are available is sufficient
> Screen reader should provide the results info on searching commands like 10 results found or suggestions available when there are any search results (Source: #7907)
2. This is common practice. Settings app and XAML Controls Gallery do this for their search box.
Also, the user should be able to know how many results were found by tabbing/selecting a result item. When this is done, the screen reader will use `SizeOfSet` and `PositionInSet` to announce how many results were found and which one we're currently on.
## Validation Steps Performed
Verified this behavior using Narrator.
Verified it matches the behavior of the Settings app and the XAML Controls Gallery.
(cherry picked from commit 1e47d7aca7)
This makes the scenario mentioned in #8480 work. It's maybe not as holistic a solution as we'd like, but it definitely works.
Tested both with Narrator, and using the TabView scroll handles to get tab focus into the tab row manually
* [x] Closing the _active_ tab with <kbd>Ctrl+Shift+w</kbd> works (not the `TabViewItem` that has focus, but that's how Edgium works so that seems fine)
* [x] Opening a tab with <kbd>Ctrl+Shift+t</kbd> works
* [x] Opening the cmdpal with <kbd>Ctrl+Shift+p</kbd> works
* [x] Will take care of #8480 once we get the a11y team to validate
* [x] I work here
#### Notes:
None of
```xaml
PreviewKeyDown="_KeyDownHandler"
KeyDown="_KeyDownHandler"
KeyUp="_KeyDownHandler"
```
On the TerminalPage directly seem to fire when the focus is in the `TabViewItem` or the New Tab flyout. But they fire just fine when focus is in the `TermControl`. Interesting, because you'd think that the `TermControl` would have already handled the key...
(cherry picked from commit 6f69487829)
## Summary of the Pull Request
Makes `Model::DefaultTerminal` an `IStringable`, which presents it as a string, when possible. This enables text search for defterm's setting. This also enables screen readers to identify the combo box items by their text content (app name, author, and version) as opposed to being treated as an item containing more text. As a part of that, I cleaned up the UIA tree to treat the item's name as "\<name\>, \<author\>, \<version\>". This is consistent with how the Settings App presents installed apps in Apps > Installed apps.
#11251 will be resolved upon verification by the accessibility team.
## Validation Steps Performed
Verified using Narrator and Accessibility Insights.
(cherry picked from commit d89c241dac)
The PGO helpers NuGet had the Y2K22 bug. This receives and integrates the updated package in our project to restore NuGet functionality.
## PR Checklist
* [x] Closes#12261
* [x] I work here
* [x] If it builds it sits.
## Validation Steps Performed
* [x] Build new PGO instrument data with this pipeline update: https://dev.azure.com/microsoft/Dart/_build/results?buildId=44304850&view=results
(cherry picked from commit fe52368f9b)
I can find the commit where this regressed tomorrow if needed. In #10685 we stopped emitting these notifications while we were deferring cursor drawing. We however forgot to send the notification at the end of the defer.
This likely has a small perf impact. We however do need these cursor position events for IMEs to be able to track the cursor position (and low key for #10821)
* [x] regressed in #10685
* [x] Closes#11170
* [x] I work here
* [x] Tests added
(cherry picked from commit 01fd7141ed)
When title updates are forwarded from the host to the client terminal,
they're passed over conpty in an `OSC 0` sequence. If there are any
control characters embedded in that title text it's essential they be
filtered out, otherwise they are likely to be misinterpreted by the VT
parser on the other side. This PR fixes a case where that sanitization
step was missed for titles initialized at startup.
Originally the sanitization step was handled in `DoSrvSetConsoleTitleW`,
which catches title changes made via VT escape sequences, or through the
console API, but missed the title initialization at startup. I've now
moved that sanitization code into the `CONSOLE_INFORMATION::SetTitle`
method, which should cover all cases.
This sanitization is only meant to occur when in "pty mode", though,
which we were originally establishing with an `IsInVtIoMode` call.
However, `IsInVtIoMode` does not return the correct result when the
title is set at startup, since the VT I/O thread is not initialized at
that point. So I've instead had to change that to an `InConptyMode`
call, which determines the conpty state from the launch args.
## Validation Steps Performed
I've manually confirmed the test case described in issue #12206 is now
working correctly.
However, the change to using `InConptyMode` caused some of the unit
tests to fail, because there isn't a real conpty connection when
testing. Fortunately there are some `EnableConptyModeForTests` methods
used by the unit tests to fake the appearance of a conpty connection,
and I just needed to add some additional state in one of those methods
to trigger the correct `InConptyMode` response.
Closes#12206
(cherry picked from commit 3804f2672e)
This commit also introduces a check that we are in an interactive
session before we perform handoff, so as to not break service accounts.
It also adds some tracing.
Merged PR 6882227: [Git2Git] Merged PR 6881763: Change to hardcoded system GUIDs to appease manifest validation
Manifest validation won't accept migration/initialization of HKCU-based registry keys anymore. The enforcement scripts says that they should be defined in code instead. So here it is: defined in code insteead.
Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 67c720b628de4acefbc381891b7e7d29d387038e
Related work items: MSFT-37867666
In previous releases, we had the commandlines for the Command Prompt and PowerShell profiles unqualified, as `cmd.exe` and `powershell.exe`. This was bad - theoretically, that would have preferred the cmd that was in the CWD over the one in System32. Or, something could insert itself into the path, and you'd end up with a malicious `cmd.exe` before the real one.
In #11437, we made sure that the `userDefaults` are initiated with the fully qualified paths. However, that didn't fix the issue for folks who already had settings files.
In an effort to better prevent this kind of badness, if we see a profile _with a default profile guid_, AND the unqualified version of the path, then we'll stealth replace it with the fully qualified one.
* Related to #11437
* [x] fixes#12126
* [x] Tests added
(cherry picked from commit f1baa319fc)
This was a simple oversight. No user profile ever has `connectionType` set, because why would they. So even for the Azure Shell, which needed this, the check would fail and we'd forget to duplicate the connectionType to the new profile.
* [x] I work here
* [x] Closes#12120
* [x] Tested manually
(cherry picked from commit eb83469874)
This PR does two things, which are best viewed as atomic commits:
* e64ae7d: Move the `MangleStartingDirectoryForWSL` to `types/utils`. It doesn't _really_ make sense in `types`, since it's only really being used in a single place in TerminalConnection. However, TerminalConnection doesn't have tests, and types does. So this commit move the function there, and adds tests from #9223 to the types tests.
* 42036c5: This actually fixes the bug in #11994. Unfortunately, `wsl --cd` will try to treat paths starting with `//wsl$` as a linux-relative path, when the user almost certainly wanted a windows-relative one. So we'll mangle that back into a path that looks like `\\wsl$\foo\bar`.
* [x] closes#11994
* [x] I work here
* [x] tests added 🎉
(cherry picked from commit b87b809fa0)
I'm not 100% sure that this is the right solution, but it does seem to work well enough. This is unfortunately a classic heisenbug. It was already hard enough to repro originally, but attaching a debugger made it totally impossible to hit.
My theory is that it's possible for the GotFocus event to fire before the LayoutUpdated event does. If that were to occur, then we'd try to turn on the cursor timer before it exists, gracefully do nothing, then create the timer. In that case, we'd never get a subsequent message to start the blinking.
I tested that theory by just initializing the cursor blinker to our `_focused` state. In that case, if the control has already been focused at the time of the LayoutUpdated event, then we can init the cursor to the correct state. Testing that out, I couldn't once get this to repro, which makes me think this works. I've opened some 900 (<sup>hyperbole</sup>) tabs now, so I'm pretty confident I'd have seen it by now.
* Regressed in #10978
* [x] fixes#11411
* [x] I made sure I didn't regress #6586
* [x] I work here
(cherry picked from commit 55aea08d15)
<!-- 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
- Settings > Add a new profile
- Disable "Duplicate" button until a profile is selected
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Should take care of #12056, once we can get a build to the a11y team (MAINTAINER EDIT: we unfortunately can't just say "closes #foo" for issues like this one, we need another team to validate the following build.)
* [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
(cherry picked from commit a766798fb8)
<!-- 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
fix#11432
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#11432
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] 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
compiled and verified that "\~" , "/usr/bin" , "~/.config" and "/" as stating directory didn't get relative path resolve
verified that '.' did
(cherry picked from commit c98ec15144)
Ensures the PowerShell Core profile's commandline is quoted. This allows
the profile to work correctly if there are files in place on the machine
(e.g. one called `C:\Program`) that prevent `CreateProcess()` from
invoking the un-quoted commandline.
## Validation Steps Performed
Created a file called `C:\Program` and opened the PowerShell profile in
terminal.
Closes#11717
(cherry picked from commit 4930508b8c)
When copying content from the terminal to the clipboard (with
formatting), a default background color needs to be set to fill the
unused area of the pasted block. Prior to this PR, that color was not
correctly set, so the pasted content did not match what was seen on
screen.
Windows Terminal previously used the default background from the initial
color scheme, so it didn't take palette changes into account.
OpenConsole did use the active default color, but didn't take the
reverse screen mode into account, so could end up using the foreground
rather than the background color.
In both case I've changed the code to lookup the runtime colors in the
same way that renderer does, so they should now match what is seen on
screen.
I've manually confirmed that the background color is now correctly set
when copying from both Windows Terminal and OpenConsole.
Closes#11988
(cherry picked from commit b61b24ecd1)
Enables a series of tasks run against our release pipeline that validate the security and compliance status of our code in an automated fashion. These checks include:
- Component Governance - (we had this one, it was moved to here) - Inventories open-source components used in our build
- PREfast - C/C++ static analysis for common code errors and exploits
- Policheck - Searches source code, comments, and text for words that could be sensitive legally, culturally, or geopolitically
- Credscan - Looks for credentials left behind in the code/documents and build output files
- BinSkim - Searches for common vulnerabilities in binaries
- CheckCFlags - Validates that compile/link flags match the policies recommended by Windows engineering for inclusion into the OS product image
- CFGCheck/XFGCheck - Validates that the CFG and/or XFG settings were enabled at compile and link time to guard against control flow attacks.
We're also required to run the SBOM one, but that was done in a separate PR and we're still pending the detectors being updated.
- #11948 - Move from CFG to XFG once XFG task folks get back to me on it
- #11949 - Enable bug filing for SecComp tasks
- #11950 - Bulk process bugs filed by SecComp tasks
- #11947 - Validate SBOM when checkers come online
- [x] - Fixes#10735
- [x] - Fixes#908
- [x] - I work here
- [x] - If it fits, it sits.
Only look for PGO package if build mode targeted; add packages.config dependency to ease restoration
## PR Checklist
* [x] Closes#11978
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [x] Test of restore and build on fresh repo copy passed.
To unify with WinUI, we're going to share an engineering component of this particular NuGet package full of scripts and utilities to make PGOing things easier.
This basically removes all of the scripts that I ~blatantly stole~ copied from https://github.com/microsoft/microsoft-ui-xaml and moves to the NuGet package that the team generates instead. A bunch of build things had to be massaged to make it work in our pipeline.
Microsoft will be providing a Software Bill of Materials for our products. This onboards the Windows Terminal product to the common engineering system task that can scavenge for this information within our build project (already recorded for internal compliance reasons) and present it in a machine-readable interchange format.
See also: https://devblogs.microsoft.com/engineering-at-microsoft/generating-software-bills-of-materials-sboms-with-spdx-at-microsoft/
This does not yet include packaging and distributing the SBOM with our final packages. We are waiting for that tooling to come online for MSIX. Guidance is "Coming Soon™️."
## References
- https://github.com/microsoft/dropvalidator/issues/216 - `cgmanifest.json` are not being pulled in yet, but I've been told internally this will fix it. I will double-check when I hear back on this issue.
## PR Checklist
* [x] Closes#11810
* [x] I work here
* [x] I ran it and I see the manifest generated.
Revert "Fix environment block creation (#7401)"
This reverts commit 7886f16714.
(cherry picked from commit e46ba65665)
Revert "Always create a new environment block before we spawn a process (#7243)"
This reverts commit 849243af99.
References #7418
(cherry picked from commit 4204d2535c)
(cherry picked from commit f8e8572c23)
(cherry picked from commit cb4c4f7b73)
(cherry picked from commit afb0cac3e3)
(cherry picked from commit b25dc74a1d)
Just read the code, it's immediately obvious what I messed up
Closes#11645
@DHowett turns out I was wrong, I could get this one done before 5 😜
(cherry picked from commit 3667678df1)
<!-- 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
Properly handle UTF-16 surrogates when calculating the position of matched pattern.
Fix#8709
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
b88ffb21b0/src/buffer/out/search.cpp (L335-L339)
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes#8709
* [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
use `Utf16Parser::Parse` to handle code points from U+010000 to U+10FFFF in UTF-16.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
also the case by @mas90 https://github.com/microsoft/terminal/issues/8709#issuecomment-884915485:
(cherry picked from commit a2d96d6b1f)
This is a primitive bug fix for GetConsoleCommandHistoryLengthA.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
(cherry picked from commit ca20bbde1e)
<!-- 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
Clean up an invalid access that I introduced in #11440
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#11684
* [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
(cherry picked from commit 29e6235151)
We have been advised to give not only the PDB paths, but paths to the EXE and DLL files we produce, to the PublishSymbols build task. We are assured by our engineering systems teams that enlightening the task to all of this information helps it hook things up better somewhere between our build machine and the symbol server such that debugging is more robust, especially around thrown exception stacks.
## PR Checklist
* [x] Closes#11737 - main fix for feeding EXEs and DLLs into the symbol publisher
* [x] Closes#11860 - bonus fix because I noticed the PDB source linking wasn't working
* [x] I work here.
* [x] If it fits, it sits.
(cherry picked from commit 52235b0fb6)
Adds snap layout support to the Terminal's maximize button. This PR is
full of BODGY, so brace yourselves.
Big thanks to Chris Swan in #11134 for building the prototype.
I don't believe this solves #8795, because XAML islands can't get
nchittest messages
- The window procedure for the drag bar forwards clicks on its client
area to its parent as non-client clicks.
- BODGY: It also _manually_ handles the caption buttons. They exist in
the titlebar, and work reasonably well with just XAML, if the drag bar
isn't covering them.
- However, to get snap layout support, we need to actually return
`HTMAXBUTTON` where the maximize button is. If the drag bar doesn't
cover the caption buttons, then the core input site (which takes up
the entirety of the XAML island) will steal the `WM_NCHITTEST` before
we get a chance to handle it.
- So, the drag bar covers the caption buttons, and manually handles
hovering and pressing them when needed. This gives the impression that
they're getting input as they normally would, even if they're not
_really_ getting input via XAML.
- We also need to manually display the button tooltips now, because XAML
doesn't know when they've been hovered for long enough. Hence, the
`_displayToolTip` `ThrottledFuncTrailing`
## Validation
Minimized, maximized, restored down, hovered the buttons slowly, moved
the mouse over them quickly, they feel the same as before. But now with
snap layouts appearing.
## TODO!
* [x] I'm working on getting the ToolTips on the caption buttons back. Alas, I needed a demo of this _today_, so I'll fix that tomorrow morning.
* [x] mild concern: I should probably test Win 10 to make sure there wasn't weird changes to the message loop in win11 that means this is broken on win10.
* [x] I think I used the wrong issue number for tons of my comments throughout this PR. Double check that. Should be #9443, not #9447.
Closes#9443
I thought this took care of #8587 ~as a bonus, because I was here, and the fix is _now_ trivial~, but looking at the latest commit that regressed.
Co-authored-by: Chris Swan <chswan@microsoft.com>
(cherry picked from commit f2ebb21bd1)
Fixes MSFT:34673647, at least I'm pretty sure. That's only ever hit a few
times externally, and internally it's hitting a lot on 1.9.1942 builds, which
doesn't really make any sense.
(cherry picked from commit a74c37bbcd)
Window sends an event that requests exit from fullscreen then SC_RESTORE messages is sent and it is in fullscreen mode.
Closes#10607
## Validation Steps Performed
Border and tabbar now appear after exiting fullscreen via "win+arrow down".
(cherry picked from commit 7aae2e9100)
## Summary of the Pull Request
There is a non-zero subset of applications that randomly output _Locking Shift_ escape sequences which will invoke a character set from G2 or G3 into the left half of the code table. If those G-sets are mapped to Latin1, that can result in the terminal producing output that appears to be broken. This PR now defaults all G-sets to ASCII, to prevent an unintentional _Locking Shift_ from having any effect.
## PR Checklist
* [x] Closes#10408
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. Issue number where discussion took place: #10408
## Detailed Description of the Pull Request / Additional comments
Most other modern terminals also default to ASCII in all G-sets, so this shouldn't break any modern applications. Legacy 8-bit applications may still expect the G2 and G3 sets mapped to Latin1, but they would also need to have the ISO-2022 encoding enabled, so we can keep them happy by setting G2 and G3 correctly when the ISO-2022 encoding is requested.
## Validation Steps Performed
I've manually confirmed that `echo -e "\en"` and `echo -e "\eo"` no longer have any visible effect on the output (at least without first invoking another character set into G2 or G3). I've also confirmed that they do still work as expected (i.e. selecting Latin1) after enabling the ISO-2022 encoding.
(cherry picked from commit 27e042b784)
## Summary of the Pull Request
When we are on a settings UI tab, `_GetActiveControl` returns a `nullptr`, make sure not to try and focus it in that case
## PR Checklist
* [x] Closes#11633
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I work here
## Validation Steps Performed
No longer crashes
(cherry picked from commit a7ce93a357)
This is a pretty obvious typo in retrospect. Never hit it before, because in all non-defterm windows, the `_startupActions` always has one action.
* [x] Closes#11463
(cherry picked from commit b90f3605a2)
## Summary of the Pull Request
Ensures that the background image path is displayed in the settings UI.
## References
One of the items on #11353
## PR Checklist
* [x] Closes#11541
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
## Validation Steps Performed
Set the background image path and saw that it was displayed in the settings UI.
(cherry picked from commit 9662bc6910)
This commit is a minimal fix in order to pass the
`IDWriteFontCollection` we create out of .ttf files residing next to our
binaries to the `IDWriteFontFallback::MapCharacters` call. The
`IDWriteTextFormat` is used in order to carry the font collection over
into `CustomTextLayout`.
## Validation
* Put `JetBrainsMono-Regular.ttf` into the binary output directory
* Modify `HKCU:\Console\*\FaceName` to `JetBrains Mono`
* Launch OpenConsole.exe
* OpenConsole uses JetBrains Mono ✔️Closes#11032Closes#11648
(cherry picked from commit 131f5d2b32)
I can't even write a description for this. Just read the code change, you'll see what I goofed.
Regressed in #11372Closes#11555
(cherry picked from commit 1cedac6a33)
The "updates" key is an alternative "guid" key for fragment profiles.
But SettingsLoader::_appendProfile stores and deduplicates profiles according
to their "guid" only. We need to modify the function to optionally store
profiles by their "updates" key as well, otherwise multiple fragment
profiles without "guid" might collide as they produce the same default GUID.
## PR Checklist
* [x] Closes#11597
* [x] I work here
* [ ] Tests added/passed
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
## Validation Steps Performed
* Unit tests pass ✔️
* Issue #11597 doesn't reproduce anymore ✔️
(cherry picked from commit fe26a6efc0)
Fixes#11606
This is weird, but the infobars would appear totally on top of the
TerminalPage when `showTabsInTitlebar:false`. This would result in the infobar
obscuring the tabs.
Now, the infobars are strictly inserted after the tabs, before the content. So
when they appear, they will reduce the amount of space usable for the control.
That is a little annoying, but preferable to the tabs totally not existing.
Relevant conversation notes from #10798:
> > If the info bar is not local to the tab, then its location between the tab
> > bar (when the title bar is hidden) and the terminal panes feels
> > misleading. Should it instead be above the tab bar or below the terminal
> > panes?
>
> You're... not wrong here. It's maybe not the best place for it, but _on top_
> of the tabs would look insane, and probably wouldn't even work easily, given
> the way we reparent the tab row into the titlebar.
>
> In the pane itself would make more sense, but that runs abreast of all sorts
> of things like #9024, #4998, which might make more sense.
I'm just gonna go with this now, because it's _better_ than before, while we
work out what's _best_.
(cherry picked from commit a916a5d9de)
After this commit OpenConsoleProxy will be built without a CRT.
This cuts down its binary size and DLL dependency bloat.
We hope that this fixes a COM server activation bug if the
user doesn't have a CRT installed globally on their system.
Fixes#11529
(cherry picked from commit def1bdd693)
Since the settings UI's input fields behave similarly to the terminal's input,
`TerminalPage::_KeyDownHandler` also needs to behave similarly to
`TermControl::_KeyHandler`. This commit copies all relevant code
over from the latter into the former, including the suppression
of AltGr keys for keychord/action handling.
## PR Checklist
* [x] Closes#11788
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Use a German keyboard layout
* Open 2 regular tabs and 1 settings tab and focus an input field
* AltGr+2 produces the character ² ✔️
* Ctrl+Alt+2 opens the second tab ✔️
(cherry picked from commit 80f8383860)
@@ -99,29 +99,15 @@ If you don't have any additional info/context to add but would like to indicate
## Contributing fixes / features
If you're able & willing to help fix issues and/or implement features, we'd love your contribution!
The best place to start is the list of ["Easy Starter"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+label%3A%22Easy+Starter%22+) issues. These are bugs or tasks that we on the team believe would be easier to implement for someone without any prior experience in the codebase. Once you're feeling more comfortable in the codebase, feel free to just use the ["Help Wanted"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+) label, or just find an issue your interested in and hop in!
Generally, we categorize issues in the following way, which is largely derived from our old internal work tracking system:
* ["Bugs"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Bug%22+) are parts of the Terminal & Console that are not quite working the right way. There's code to already support some scenario, but it's not quite working right. Fixing these is generally a matter of debugging the broken functionality and fixing the wrong code.
* ["Tasks"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Task%22+) are usually new pieces of functionality that aren't yet implemented for the Terminal/Console. These are usually smaller features, which we believe
- could be a single, atomic PR
- Don't require much design consideration, or we've already written the spec for the larger feature they belong to.
* ["Features"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Feature%22+) are larger pieces of new functionality. These are usually things we believe would require larger discussion of how they should be implemented, or they'll require some complicated new settings. They might just be features that are composed of many individual tasks. Often times, with features, we like to have a spec written before development work is started, to make sure we're all on the same page (see below).
Bugs and tasks are obviously the easiest to get started with, but don't feel afraid of features either! We've had some community members contribute some amazing "feature"-level work to the Terminal (albeit, with lots of discussion 😄).
Often, we like to assign issues that generally belong to somebody's area of expertise to the team member that owns that area. This doesn't mean the community can't jump in -- they should reach out and have a chat with the assignee to see if it'd okay to take. If an issue's been assigned more than a month ago, there's a good chance it's fair game to try yourself.
For those able & willing to help fix issues and/or implement features ...
### To Spec or not to Spec
Some issues/features may be quick and simple to describe and understand. For such scenarios, once a team member has agreed with your approach, skip ahead to the section headed "Fork, Branch, and Create your PR", below.
Small issues that do not require a spec will be labelled `Issue-Bug` or `Issue-Task`.
Small issues that do not require a spec will be labelled Issue-Bug or Issue-Task.
However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled `Issue-Feature`. More often than not, we'll add such features to the ["Specification Tracker" project](https://github.com/microsoft/terminal/projects/1).
However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled Issue-Feature.
Specs help collaborators discuss different approaches to solve a problem, describe how the feature will behave, how the feature will impact the user, what happens if something goes wrong, etc. Driving towards agreement in a spec, before any code is written, often results in simpler code, and less wasted effort in the long run.
<!-- Mandatory. Minor version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Mandatory, defaults to 0. Patch version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- Optional, defaults to empty. Prerelease version number of the PGO database which should match the version of the product. This can be hardcoded or obtained from other sources in build system. -->
<!-- This file is read by XES, which we use in our Release builds. -->
<PropertyGroup Label="Version">
<!--
The Windows 11 build is going to have the same package name, so it *must* have a different version.
The easiest way for us to do this is to add 1 to the revision field.
In short, for a given Terminal build 1.11, we will emit two different versions (assume this is build
4 on day 23 of the year):
- 1.11.234.0 for Windows 10
- 1.11.235.0 for Windows 11
This presents a potential for conflicts if we want to ship two builds produced back to back on the
same day... which is terribly unlikely.
-->
<VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>
@@ -87,46 +87,3 @@ If you want to use .nupkg files instead of the downloaded Nuget package, you can
2. Create the folder /dep/packages
3. Put your .nupkg files in /dep/packages
4. If you are using different versions than those already being used, you need to update the references as well. How to do that is explained under "Updating Nuget package references".
## Building the Terminal package from the commandline
The Terminal is bundled as an `.msix`, which is produced by the `CascadiaPackage.wapproj` project. To build that project from the commandline, you can run the following (from a window you've already run `tools\razzle.cmd` in):
(yes, the cmd version is just calling powershell to do the powershell version. Too lazy to convert the rest by hand, I'm already copying from `.vscode\tasks.json`)
Building the package from VS generates the loose layout to begin with, and then registers the loose manifest, skipping the msix stop. It's a lot faster than the commandline inner loop here, unfortunately.
"description":"When set to true, we will (when necessary) adjust the foreground color to make it more visible, based on the background color.",
"type":"boolean"
},
"experimental.retroTerminalEffect":{
"description":"When set to true, enable retro terminal effects when unfocused. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean"
@@ -281,7 +277,6 @@
"ShortcutActionName":{
"enum":[
"adjustFontSize",
"clearBuffer",
"closeOtherTabs",
"closePane",
"closeTab",
@@ -290,7 +285,6 @@
"commandPalette",
"copy",
"duplicateTab",
"exportBuffer",
"find",
"findMatch",
"focusPane",
@@ -332,18 +326,13 @@
"tabSearch",
"toggleAlwaysOnTop",
"toggleFocusMode",
"setFocusMode",
"toggleFullscreen",
"setFullScreen",
"setMaximized",
"togglePaneZoom",
"toggleSplitOrientation",
"toggleReadOnlyMode",
"toggleShaderEffects",
"wt",
"quit",
"adjustOpacity",
"restoreLastClosed",
"unbound"
],
"type":"string"
@@ -437,14 +426,6 @@
],
"type":"string"
},
"ClearBufferType":{
"enum":[
"all",
"screen",
"scrollback"
],
"type":"string"
},
"NewTerminalArgs":{
"properties":{
"commandline":{
@@ -480,12 +461,7 @@
"colorScheme":{
"description":"The name of a color scheme to use, instead of the one specified by the profile",
"type":"string"
},
"elevate":{
"type":"boolean",
"default":false,
"description":"This will override the profile's `elevate` setting."
},
}
},
"type":"object"
},
@@ -843,66 +819,6 @@
"colorScheme"
]
},
"SetFocusModeAction":{
"description":"Arguments for a setFocusMode action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"setFocusMode"
},
"isFocusMode":{
"type":"boolean",
"description":"whether focus mode is enabled"
}
}
}
],
},
"SetFullScreenAction":{
"description":"Arguments for a setFullScreen action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"setFullScreen"
},
"isFullScreen":{
"type":"boolean",
"description":"whether the window should be full screen"
}
}
}
],
},
"SetMaximizedAction":{
"description":"Arguments for a setMaximized action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"setMaximized"
},
"isMaximized":{
"type":"boolean",
"description":"whether the window should be maximized"
}
}
}
],
},
"WtAction":{
"description":"Arguments corresponding to a wt Action",
"allOf":[
@@ -1277,48 +1193,6 @@
}
]
},
"ClearBufferAction":{
"description":"Arguments corresponding to a clearBuffer Action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"clearBuffer"
},
"clear":{
"$ref":"#/$defs/ClearBufferType",
"default":"all",
"description":"What to clear. Accepts one of `screen`, `scrollback` or `all` (for both)."
}
}
}
]
},
"ExportBufferAction":{
"description":"Arguments corresponding to a exportBuffer Action",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"exportBuffer"
},
"path":{
"type":"string",
"default":"",
"description":"The path to export the text buffer to. If left blank, the Terminal will open a file picker to choose the path."
}
}
}
]
},
"GlobalSummonAction":{
"description":"This is a special action that works globally in the OS, rather than only in the context of the terminal window. When pressed, this action will summon the terminal window.",
"allOf":[
@@ -1386,34 +1260,6 @@
}
]
},
"AdjustOpacityAction":{
"description":"Changes the opacity of the active Terminal window. If `relative` is specified, then this action will increase/decrease relative to the current opacity.",
"allOf":[
{
"$ref":"#/$defs/ShortcutAction"
},
{
"properties":{
"action":{
"type":"string",
"const":"adjustOpacity"
},
"opacity":{
"type":"integer",
"minimum":-100,
"maximum":100,
"default":0,
"description":"How opaque the terminal should become or how much the opacity should be changed by, depending on the value of `relative`"
},
"relative":{
"type":"boolean",
"default":true,
"description":"If true, then adjust the current opacity by the given `opacity` parameter, additively. If false, set the opacity to exactly that value."
}
}
}
]
},
"Keybinding":{
"additionalProperties":false,
"properties":{
@@ -1510,21 +1356,12 @@
{
"$ref":"#/$defs/FocusPaneAction"
},
{
"$ref":"#/$defs/ExportBufferAction"
},
{
"$ref":"#/$defs/ClearBufferAction"
},
{
"$ref":"#/$defs/GlobalSummonAction"
},
{
"$ref":"#/$defs/QuakeModeAction"
},
{
"$ref":"#/$defs/AdjustOpacityAction"
},
{
"type":"null"
}
@@ -1637,11 +1474,6 @@
"description":"When set to true, trailing white-spaces will be removed from text in rectangular (block) selection while copied to your clipboard. When set to false, the white-spaces will be preserved.",
"type":"boolean"
},
"trimPaste":{
"default":true,
"description":"When enabled, the Terminal will automatically trim trailing whitespace characters when pasting text",
"type":"boolean"
},
"experimental.detectURLs":{
"default":true,
"description":"When set to true, URLs will be detected by the Terminal. This will cause URLs to underline on hover and be clickable by pressing Ctrl.",
@@ -1709,7 +1541,7 @@
},
"startOnUserLogin":{
"default":false,
"description":"When set to true, this enables the launch of Windows Terminal at startup. Setting this to false will disable the startup task entry. If the Windows Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect.",
"description":"When set to true, this enables the launch of Terminal at startup. Setting this to false will disable the startup task entry. If the Terminal startup task entry is disabled either by org policy or by user action this setting will have no effect.",
"type":"boolean"
},
"firstWindowPreference":{
@@ -2046,11 +1878,6 @@
],
"type":"string"
},
"elevate":{
"type":"boolean",
"default":false,
"description":"When true, this profile should always open in an elevated context. If the window isn't running as an Administrator, then a new elevated window will be created."
},
"experimental.retroTerminalEffect":{
"description":"When set to true, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed.",
"type":"boolean"
@@ -2152,10 +1979,6 @@
}
]
},
"adjustIndistinguishableColors":{
"description":"When set to true, we will (when necessary) adjust the foreground color to make it more visible, based on the background color.",
"type":"boolean"
},
"scrollbarState":{
"default":"visible",
"description":"Defines the visibility of the scrollbar.",
This document outlines the roadmap of features we're planning for the Windows Terminal during 2022. This serves as a successor to the [Terminal v2 Roadmap], to reflect changes to our planning going forward.
Initially we had planned on a discrete "Terminal v2" goal, but over the last 18 months it's become clear to the team that we don't need a strict "2.0" release. We can continue serving the community effectively with continual, incremental updates. Should a future release warrant a substantial change to the Terminal worthy of the "2.0" moniker, we can re-evaluate then.
In 2022, we're going to try tracking our overall work with two "semester" milestones, "[22H1]" and "[22H2]", which roughly align with internal deadlines. Although the Windows Terminal ships updates out-of-band from the rest of the OS, we still have commitments to fixing bugs in the broader console ecosystem. Those changes need to be made in sync with the rest of the OS. Aligning our external milestones with those deadlines should help make sure we get bugs resolved in a timely fashion and checked into the OS.
These have additionally inherited the remainder of the work that was originally targeting the Terminal v2 milestone. As we burn down the features and bugs in these milestones, we'll draw new features into them from the "[Up Next]" milestone, which is itself populated from the highest-priority elements of the [Backlog].
## Milestones
Windows Terminal is engineered and delivered as a set of 6-week milestones. New features will go into [Windows Terminal Preview](https://aka.ms/terminal-preview) first, then a month after they've been in Preview, those features will move into [Windows Terminal](https://aka.ms/terminal). These timelines are rough estimates, not strict rules.
## Terminal Roadmap / Timeline
Below is the schedule for when milestones will be included in release builds of Windows Terminal and Windows Terminal Preview. The dates are rough estimates and are subject to change.
| Milestone End Date | Milestone Name | Preview Release Blog Post |
| 2020-06-18 | [1.1] in Windows Terminal Preview | [Windows Terminal Preview 1.1 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-1-release/) |
| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | [Windows Terminal Preview 1.2 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/) |
| 2020-08-31 | [1.3] in Windows Terminal Preview<br>[1.2] in Windows Terminal | [Windows Terminal Preview 1.3 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-3-release/) |
| 2020-09-30 | [1.4] in Windows Terminal Preview<br>[1.3] in Windows Terminal | [Windows Terminal Preview 1.4 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-4-release/) |
| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | [Windows Terminal Preview 1.5 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-5-release/) |
| 2021-01-31 | [1.6] in Windows Terminal Preview<br>[1.5] in Windows Terminal | [Windows Terminal Preview 1.6 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-6-release/) |
| 2021-03-01 | [1.7] in Windows Terminal Preview<br>[1.6] in Windows Terminal | [Windows Terminal Preview 1.7 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-7-release/) |
| 2021-04-14 | [1.8] in Windows Terminal Preview<br>[1.7] in Windows Terminal | [Windows Terminal Preview 1.8 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-8-release/) |
| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/) |
| 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-10-release/) |
| 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-11-release/) |
| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-12-release/) |
| | [1.13] in Windows Terminal Preview<br>[1.12] in Windows Terminal | |
| | [1.14] in Windows Terminal Preview<br>[1.13] in Windows Terminal | |
## Issue Triage & Prioritization
Incoming issues/asks/etc. are triaged several times a week, labeled appropriately, and assigned to a milestone in priority order:
* P0 (serious crashes, data loss, etc.) issues are scheduled to be dealt with ASAP. These go in the current release milestone (e.g. at time of writing, these would go into 1.13).
* P1 issues/features/asks are typically assigned to the current or the following release milestone.
* P2 & P3 issues will typically go in the second semester for the year.
* Accessibility and Console issues that need to go into the Windows OS typically go into the current semester.
* Issues/features/asks not related to existing features in the 22H1/22H2 semesters are assigned to the [Backlog] for subsequent triage, prioritization & scheduling.
@@ -114,7 +114,7 @@ The jumplist will have to be saved each time a profile change occurs but the fre
#### Should it open a new instance of the terminal or open in a new tab?
#### What should happen if a non existent profile is launched
#### What should happen if a non existant profile is launched
The jumplist is only updated when the application is running so the profiles could be modified or deleted outside and the jumplist will not be updated. Handling will be done by whatever handles the command line parsing.
> This document has been superseded by the [Terminal 2022 Roadmap]. Please refer to that document for the updated roadmap.
## Overview
This document outlines the roadmap towards delivering Windows Terminal 2.0.
This document outlines the roadmap towards delivering Windows Terminal 2.0 by Winter 2021.
## Milestones
@@ -35,7 +31,9 @@ Below is the schedule for when milestones will be included in release builds of
| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/) |
| 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-10-release/) |
| 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-11-release/) |
| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-12-release/) |
| 2021-10-31 | 1.12 in Windows Terminal Preview<br>1.11 in Windows Terminal | |
| 2021-11-30 | 2.0 RC in Windows Terminal Preview<br>2.0 RC in Windows Terminal | |
| 2021-12-31 | [2.0] in Windows Terminal Preview<br>[2.0] in Windows Terminal | |
## Issue Triage & Prioritization
@@ -51,32 +49,28 @@ The following are a list of the key scenarios we're aiming to deliver for Termin
> 👉 Note: There are many other features that don't fit within 2.0, but will be re-assessed and prioritized for 3.0, the plan for which will be published in 2021.
| Priority\* | Scenario | Description/Notes | State |
| 0 | Settings UI | A user interface that connects to settings.json. This provides a way for people to edit their settings without having to edit a JSON file.<br><br>Issue: [#1564]<br>Specs: [#6720], [#6904]<br>Implementation: [#7283], [#7370], [#8048] | ✔️ |
| 0 | Command palette | A popup menu to list possible actions and commands.<br><br>Issues: [#5400], [#2046]<br>Spec: [#2193]<br>Implementation: [#6635] | ✔️ |
| 1 | Tab tear-off | The ability to tear a tab out of the current window and spawn a new window or attach it to a separate window.<br><br>Issue: [#1256], [#5000]<br>Spec: [#2080], [#7240] | 📝 |
| 1 | Clickable links | Hyperlinking any links that appear in the text buffer. When clicking on the link, the link will open in your default browser.<br><br>Issue: [#574]<br>Implementation: [#7251] | ✔️ |
| 1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal<br><br>Issue: [#492]<br>Spec: [#2080], [#7414] | ✔️ |
| 1 | Overall theme support | Tab coloring, title bar coloring, pane border coloring, pane border width, definition of what makes a theme<br><br>Issue: [#3327]<br>Spec: [#5772] | 🦶 |
| 1 | Open profile elevated | Configure profiles to always open elevated (if Terminal was run unelevated)<br><br>Issue: [#5000], [#632]<br>Spec: [#8455] | 📝 |
| 1 | Open tab in existing window | Open new tabs in existing Terminal windows<br><br>Issue: [#5000], [#4472]<br>Spec: [#8135] | ✔️ |
| 1 | Traditional opacity | Have a transparent background without the acrylic blur.<br><br>Issue: [#603] | ✔️ |
| 2 | SnapOnOutput, scroll lock | Pause output or scrolling on click.<br><br>Issue: [#980]<br>Spec: [#2529]<br>Implementation: [#6062] | ✔️ |
| 2 | Infinite scrollback | Have an infinite history for the text buffer.<br><br>Issue: [#1410] | 🦶 |
| 2 | Pane management | All issues listed out in the original issue. Some features include pane resizing with mouse, pane zooming, and opening a pane by prompting which profile to use.<br><br>Issue: [#1000] | 📝 |
| 2 | Theme marketplace | Marketplace for creation and distribution of themes.<br>Dependent on overall theming | 🦶 |
| 2 | Jump list | Show profiles from task bar (on right click)/start menu.<br><br>Issue: [#576]<br>Implementation: [#7515] | ✔️ |
| 2 | Open with multiple tabs | A setting that allows Windows Terminal to launch with a specific tab configuration (not using only command line arguments).<br><br>Issue: [#756] | ✔️ |
| 3 | Open in Windows Terminal | Functionality to right click on a file or folder and select Open in Windows Terminal.<br><br>Issue: [#1060]<br>Implementation: [#6100] | ✔️ |
| 3 | Session restoration | Launch Windows Terminal and the previous session is restored with the proper tab and pane configuration and starting directories.<br><br>Issues: [#961], [#960], [#766] | ✔️ |
| 3 | Quake mode | Provide a quick launch terminal that appears and disappears when a hotkey is pressed.<br><br>Issue: [#653] | ✔️ |
| 3 | Settings migration infrastructure | Migrate people's settings without breaking them. Hand-in-hand with settings UI. | 🦶 |
| 3 | Pointer bindings | Provide settings that can be bound to the mouse.<br><br>Issue: [#1553] | 🦶 |
* 📝: The feature is currently in progress
* ✔️: The feature is complete and shipped in a Preview build
* 🦶: The feature is at risk of being punted to a future release cycle (beyond 2.0)
| Priority\* | Scenario | Description/Notes |
| ---------- | -------- | ----------------- |
| 0 | Settings UI | A user interface that connects to settings.json. This provides a way for people to edit their settings without having to edit a JSON file.<br><br>Issue: [#1564]<br>Specs: [#6720], [#6904]<br>Implementation: [#7283], [#7370], [#8048] |
| 0 | Command palette | A popup menu to list possible actions and commands.<br><br>Issues: [#5400], [#2046]<br>Spec: [#2193]<br>Implementation: [#6635] |
| 1 | Tab tear-off | The ability to tear a tab out of the current window and spawn a new window or attach it to a separate window.<br><br>Issue: [#1256], [#5000]<br>Spec: [#2080], [#7240] |
| 1 | Clickable links | Hyperlinking any links that appear in the text buffer. When clicking on the link, the link will open in your default browser.<br><br>Issue: [#574]<br>Implementation: [#7251] |
| 1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal<br><br>Issue: [#492]<br>Spec: [#2080], [#7414] |
| 1 | Overall theme support | Tab coloring, title bar coloring, pane border coloring, pane border width, definition of what makes a theme<br><br>Issue: [#3327]<br>Spec: [#5772] |
| 1 | Open profile elevated | Configure profiles to always open elevated (if Terminal was run unelevated)<br><br>Issue: [#5000], [#632]<br>Spec: [#8455] |
| 1 | Open tab in existing window | Open new tabs in existing Terminal windows<br><br>Issue: [#5000], [#4472]<br>Spec: [#8135] |
| 1 | Traditional opacity | Have a transparent background without the acrylic blur.<br><br>Issue: [#603] <br>**Current State**: Blocked on WinUI 3.0 |
| 2 | SnapOnOutput, scroll lock | Pause output or scrolling on click.<br><br>Issue: [#980]<br>Spec: [#2529]<br>Implementation: [#6062] |
| 2 | Infinite scrollback | Have an infinite history for the text buffer.<br><br>Issue: [#1410] |
| 2 | Pane management | All issues listed out in the original issue. Some features include pane resizing with mouse, pane zooming, and opening a pane by prompting which profile to use.<br><br>Issue: [#1000] |
| 2 | Theme marketplace | Marketplace for creation and distribution of themes.<br>Dependent on overall theming |
| 2 | Jump list | Show profiles from task bar (on right click)/start menu.<br><br>Issue: [#576]<br>Implementation: [#7515] |
| 2 | Open with multiple tabs | A setting that allows Windows Terminal to launch with a specific tab configuration (not using only command line arguments).<br><br>Issue: [#756] |
| 3 | Open in Windows Terminal | Functionality to right click on a file or folder and select Open in Windows Terminal.<br><br>Issue: [#1060]<br>Implementation: [#6100] |
| 3 | Session restoration | Launch Windows Terminal and the previous session is restored with the proper tab and pane configuration and starting directories.<br><br>Issues: [#961], [#960], [#766] |
| 3 | Quake mode | Provide a quick launch terminal that appears and disappears when a hotkey is pressed.<br><br>Issue: [#653] |
| 3 | Settings migration infrastructure | Migrate people's settings without breaking them. Hand-in-hand with settings UI. |
| 3 | Pointer bindings | Provide settings that can be bound to the mouse.<br><br>Issue: [#1553] |
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
