terminal: Windows Terminal (Preview) crashes with wrapped text
❗ N.B. This issue has also been reported via Feedback Hub link https://aka.ms/AAa8g4n (video/screenshots have been uploaded; posted 2 months ago, but still no resolution)
Environment
Windows build number: 10.0.19042.0
Windows Terminal version: 1.5.3242.0
Any other software?
Windows Terminal version: 1.4.3243.0
Steps to reproduce
-
Open new Windows Terminal tab or window (using Windows Powershell in this case)
-
Paste a long text string WITHOUT pressing ENTER.
For example, this string (H/T http://powershell-guru.com/):
Get-ChildItem -Path C:\Demo -Filter *.cs | Rename-Item -NewName {[System.IO.Path]::ChangeExtension($_.Name, ".kt")}Any long string of ASCII characters should also reproduce issue:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-The text will soft wrap in a standard Windows Terminal configuration (12pt text)
-
Press backspace and begin deleting the text.
Expected behavior
The cursor should move up a line. Windows Terminal should not crash.
Actual behavior
Windows Terminal crashes just before the cursor moves up a line, or in other words, just before the character where the text is wrapped.
NOTE: This only appears to happen when there is one tab open.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 22 (11 by maintainers)
Commits related to this issue
- Validate cursor position in UIA UTR ctor (#12436) This adds some validation in the `UiaTextRange` ctor for the cursor position. #8730 was caused by creating a `UiaTextRange` at the cursor position... — committed to microsoft/terminal by carlos-zamora 2 years ago
- Validate cursor position in UIA UTR ctor (#12436) This adds some validation in the `UiaTextRange` ctor for the cursor position. #8730 was caused by creating a `UiaTextRange` at the cursor position... — committed to microsoft/terminal by carlos-zamora 2 years ago
- Validate cursor position in UIA UTR ctor (#12436) This adds some validation in the `UiaTextRange` ctor for the cursor position. #8730 was caused by creating a `UiaTextRange` at the cursor position w... — committed to microsoft/terminal by carlos-zamora 2 years ago
- Update Component Parts: (#1) * Prevent potential null pointer crash in export buffer action (#12180) ## Summary of the Pull Request Prevents a potential null pointer crash in the export buffer a... — committed to FOSS-Archives/microterminal by Daasin 2 years ago
- Validate cursor position in UIA UTR ctor (#12436) This adds some validation in the `UiaTextRange` ctor for the cursor position. #8730 was caused by creating a `UiaTextRange` at the cursor position w... — committed to microsoft/terminal by carlos-zamora 2 years ago
Apologies if this is unhelpful noise but just a super delighted partially blind customer here wanting to validate that this bug is actually fixed in the wild!
I can run ‘npm i -g gatsby-cli’ now without Windows Terminal silently crashing! THIS MADE MY MONTH! 😃 Hearty thanks to all concerned. If you ever find yourself in Boston please look me up there’s a beverage with your name on it 😃
It’s my fault. If you want to shock my chair, you can. I realize, like many things, this was a mistake in hindsight.
In the meantime, though, we should really get rid of those damn
FAIL_FASTtests. Or anyone that is in favour of retaining them, should volunteer to have the telemetry from the crash logs wired up to their desk with a high-voltage shock.@feoh thanks for the kind words! That really made the team’s day 😄
Thank you all for your hard work on this issue. It’s a real quality of life buzzkill and I appreciate us being on a path to a fix!
Sorry I didn’t look at this sooner! Somehow this never made it to the top of my inbox.
So here’s what’s going on:
ScreenInfoUiaProviderBase::GetSelection()is calledUiaTextRangeBase::GetBoundingRectangles()is calledViewport::CompareInBounds(<cursorPosition>, <topOfViewport>)is called and crashes because<cursorPosition>is out of bounds from the buffer size (as mentioned above).I’m hesitant to clamp the coordinate because I feel like the coordinate is wrong in the first place. Why is the cursor position
{120,8}when the buffer is 120 cells wide? The cursor should be going from{0,9}to{119,8}when it wraps.@miniksa @lhecker Any idea why the cursor’s position would be off the right boundary? I imagine we’re using the
OutputCellIterator(or one of the iterators we have) to wrap the cursor properly, so that’s the part that’s confusing to me.@carlos-zamora I’m deferring this one to you. Seems like we could easily just add a check to see if
startAnchor.x() >= bufferSize.RightExclusive(), and clamp the coordinate in that case. But maybeViewport::IsInBounds(..., allowEndExclusive=true)needs to be more forgiving for this scenario? IDK.It should definitely get a test though, and you’re the UIA test man for sure.
For what it’s worth anyone trying to use nodejs / npm on Windows is going to get bitten REALLY hard by this bug. It makes installing packages almost impossible.
Triaging this into v2 since we have a line of code identified. Thanks!