Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminal crashes when starting nano in bash when screen reader is enabled #13183

Closed
LeonarddeR opened this issue May 26, 2022 · 8 comments · Fixed by #13250
Closed

Terminal crashes when starting nano in bash when screen reader is enabled #13183

LeonarddeR opened this issue May 26, 2022 · 8 comments · Fixed by #13250
Assignees
Labels
Area-Accessibility Issues related to accessibility Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Severity-Blocking We won't ship a release like this! No-siree. Severity-Crash Crashes are real bad news.

Comments

@LeonarddeR
Copy link

Windows Terminal version

1.14.1433.0 preview

Windows build number

22621.1

Other Software

  • Nano in either WSL or ssh
  • Narrator or NVDA 2022.1

Steps to reproduce

  1. Start wsl from the terminal
  2. Type nano test

Expected Behavior

Nano opens as expected

Actual Behavior

WT crashes

@LeonarddeR LeonarddeR added the Issue-Bug It either shouldn't be doing this or needs an investigation. label May 26, 2022
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels May 26, 2022
@LeonarddeR
Copy link
Author

Cc @codeofdusk, can you reproduce this?

@codeofdusk
Copy link
Contributor

I wonder if #12561 is related?

CC @carlos-zamora, @zadjii-msft.

@j4james
Copy link
Collaborator

j4james commented May 26, 2022

FYI, I can reproduce this in vim too. It's another example of a FAIL_FAST crash in Viewport::CompareInBounds - same as #8730. I know we need to track down the source of the incorrect coordinates as well, but can we please, please, please get rid of those FAIL_FAST calls.

@zadjii-msft zadjii-msft added Area-Accessibility Issues related to accessibility Severity-Crash Crashes are real bad news. Product-Terminal The new Windows Terminal. Severity-Blocking We won't ship a release like this! No-siree. Priority-0 Bugs that we consider release-blocking/recall-class (P0) labels May 26, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 26, 2022
@zadjii-msft zadjii-msft added this to the Terminal v1.14 milestone May 26, 2022
@zadjii-msft zadjii-msft added Needs-Tag-Fix Doesn't match tag requirements Needs-Discussion Something that requires a team discussion before we can proceed labels May 26, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 26, 2022
@j4james
Copy link
Collaborator

j4james commented May 26, 2022

As far as I can see, the value that's out of range is coming from the _getDocumentEnd call, and the reason that's out of range is because GetLastNonSpaceCharacter is wrong. The reason that is wrong, is because the viewport passed to it from _getOptimizedBufferSize is wrong. And the reason that is wrong, is because GetTextBufferEndPosition is wrong. GetTextBufferEndPosition gets its Y coordinate from ViewEndIndex, and when we're in the alt buffer, that returns the buffer height, when it should be the height minus one (I believe it's meant to be the index of the last line).

In short, we need to change the value in Terminal::ViewEndIndex to _altBufferSize.height-1. See here:

int Terminal::ViewEndIndex() const noexcept
{
return _inAltBuffer() ? _altBufferSize.height : _mutableViewport.BottomInclusive();
}

That said, the original alt buffer implementation (PR #12561) actually had this correct. It was in PR #12719 that it was essentially changed from height-1 to height. If that was an intentional change, the fix may be more complicated that it first appears.

@zadjii-msft
Copy link
Member

If that was an intentional change, the fix may be more complicated that it first appears.

I really doubt it was. This one's on me I suppose. Thanks for the initial investigation!

@zadjii-msft
Copy link
Member

note before lunch: after replacing that with a height-1, there's still a crash after moving the cursor down some rows.

 	Microsoft.Terminal.Control.dll!wil::details::in1diag5::FailFast_If(void * callerReturnAddress, unsigned int lineNumber, const char * fileName, const char * functionName, const char * code, bool condition) Line 5435	C++
 	Microsoft.Terminal.Control.dll!Microsoft::Console::Types::Viewport::CompareInBounds(const _COORD & first, const _COORD & second, bool allowEndExclusive) Line 369	C++
>	Microsoft.Terminal.Control.dll!Microsoft::Console::Types::UiaTextRangeBase::_expandToEnclosingUnit(TextUnit unit) Line 296	C++
 	Microsoft.Terminal.Control.dll!Microsoft::Console::Types::UiaTextRangeBase::ExpandToEnclosingUnit(TextUnit unit) Line 273	C++
 	Microsoft.Terminal.Control.dll!winrt::Microsoft::Terminal::Control::implementation::XamlUiaTextRange::ExpandToEnclosingUnit(winrt::Windows::UI::Xaml::Automation::Text::TextUnit unit) Line 67	C++
  Name Value Type
_start {56,167} _COORD
bufferSize {LT(0, 0) RB(79, 22) [80 x 23]} Microsoft::Console::Types::Viewport
documentEnd {x=0 X=0 y=23 ...} til::point

@zadjii-msft zadjii-msft removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Discussion Something that requires a team discussion before we can proceed labels Jun 6, 2022
@ghost ghost added the In-PR This issue has a related PR label Jun 8, 2022
@ghost ghost closed this as completed in #13250 Jun 10, 2022
ghost pushed a commit that referenced this issue Jun 10, 2022
## Summary of the Pull Request
This fixes the crashes caused by using a screen reader when in an app that uses the alt buffer via two changes:
1. Fix `Terminal::ViewEndIndex()`
   - `UiaTextRangeBase` receives a coordinate that is outside of the bounds of the text buffer via the following chain of functions... `_getDocumentEnd()` --> `GetLastNonSpaceCharacter()` --> `_getOptimizedBufferSize()` --> `GetTextBufferEndPoisition()` --> `ViewEndIndex()`
   - Since support for the alt buffer was added recently, `ViewEndIndex()` was recently changed, so that explains why this issue came up recently. We were accidentally setting the view end index to `height` instead of `height-1`. Thanks @j4james for finding this!
   - The UIA code would get the "exclusive end" of the alt buffer. Since it was using `ViewEndIndex()` to calculate that, it was one more than it should be. The UIA code has explicit allowance for "one past the end of the viewport" in its `IsInBounds()` check. Since the `ViewEndIndex()` is way beyond that, it's not allowed, hitting the fail fast.
2. Replace `FAIL_FAST_IF` with `assert`
   - These fail fast calls have caused so many issues with our UIA code. Those checks still provide value, but they shouldn't take the whole app down. This change replaces the `Viewport` and `UiaTextRangeBase` fail fasts with asserts to still perform those checks, but not take down the entire app in release builds.

Closes #13183 

## Validation Steps Performed
While using Narrator...
- opened nano in bash
- generated text and scrolled in nano
- generated text and scrolled in PowerShell
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jun 10, 2022
DHowett pushed a commit that referenced this issue Jun 30, 2022
This fixes the crashes caused by using a screen reader when in an app that uses the alt buffer via two changes:
1. Fix `Terminal::ViewEndIndex()`
   - `UiaTextRangeBase` receives a coordinate that is outside of the bounds of the text buffer via the following chain of functions... `_getDocumentEnd()` --> `GetLastNonSpaceCharacter()` --> `_getOptimizedBufferSize()` --> `GetTextBufferEndPoisition()` --> `ViewEndIndex()`
   - Since support for the alt buffer was added recently, `ViewEndIndex()` was recently changed, so that explains why this issue came up recently. We were accidentally setting the view end index to `height` instead of `height-1`. Thanks @j4james for finding this!
   - The UIA code would get the "exclusive end" of the alt buffer. Since it was using `ViewEndIndex()` to calculate that, it was one more than it should be. The UIA code has explicit allowance for "one past the end of the viewport" in its `IsInBounds()` check. Since the `ViewEndIndex()` is way beyond that, it's not allowed, hitting the fail fast.
2. Replace `FAIL_FAST_IF` with `assert`
   - These fail fast calls have caused so many issues with our UIA code. Those checks still provide value, but they shouldn't take the whole app down. This change replaces the `Viewport` and `UiaTextRangeBase` fail fasts with asserts to still perform those checks, but not take down the entire app in release builds.

Closes #13183

While using Narrator...
- opened nano in bash
- generated text and scrolled in nano
- generated text and scrolled in PowerShell

(cherry picked from commit 94e1697)
Service-Card-Id: 82972865
Service-Version: 1.14
ghost pushed a commit that referenced this issue Jul 1, 2022
## Summary of the Pull Request
Replaces most uses of `Viewport::CompareInBounds()` with `til::point`'s `<` and `>` operators. `CompareInBounds` has been the cause of a bunch of UIA crashes over the years. Replacing them entirely ensures that the `FAILFAST_IF` isn't ever touched.

Unfortunately, we still need `IncrementInBounds` and `DecrementInBounds` to have support for that exclusive end.

## References
#13183
@ghost
Copy link

ghost commented Jul 6, 2022

🎉This issue was addressed in #13250, which has now been successfully released as Windows Terminal v1.14.186.:tada:

Handy links:

@ghost
Copy link

ghost commented Jul 6, 2022

🎉This issue was addressed in #13250, which has now been successfully released as Windows Terminal Preview v1.15.186.:tada:

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Accessibility Issues related to accessibility Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Severity-Blocking We won't ship a release like this! No-siree. Severity-Crash Crashes are real bad news.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants