"Less" pager on Linux closes Windows Terminal

[Charlweed]

Windows Terminal version

1.14.1451.0

Windows build number

10.0.19044.0

Other Software

OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
Less version 551-1ubuntu0.1

Steps to reproduce

less /var/log/boot.log.1
Closes the window, if the count of lines in the file is more than a screen.
Similarly,
find ~/ -type f | less
Closes the window, if "find" returns more lines than fit on a screen.

Expected Behavior

The window should remain open.

Actual Behavior

When I use Windows Terminal and ssh to connect to remote linux machines, and I use the "less" pager to view a text file, the text is displayed on the terminal, and then the terminal window closes. It seems like Terminal closes after less prints its command prompt. Only the one connection window closes, other terminal windows remain open.
Other pagers (i.e. "more") do not close terminal. The less pager does not close the legacy "command prompt" window, nor the Conemu console.
This is a new issue, I have used Windows Terminal for quite a while, and this just started happening recently. I have not yet tested Terminal versions previous to 1.14.1451.0 for this issue.

[zadjii-msft]

/feedback

[ghost]

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

[azc100]

I have the same problem with Vim (regular vim, not gvim), in Ubuntu 22.04 LTS. After the initial screen of Vim is visualized, the whole Windows Terminal session goes down without any message. I reported the problem on the Feedback Hub, but nobody cared to answer in any way: "WIndows Terminal preview is broken" My version of Windows Terminal Preview is: 1.14.1452.0. Vim is vim 8.2.5085, I recompile it almost every day. Anyway, the problem is present even using the distributed /usr/bin/vim 8.2.3995.

[zadjii-msft]

@azc100 can you find the feedback you filed and share the link to it here? It's kinda hard to find them on the backend without that link 😕

FWIW I'm trying this out with my own Ubuntu 22.04 install over here, with less 590, and I can't repro this with something like less /var/log/dpkg.log.

Idly, I wonder if this is the same crash as #13250. I've got a build that has that PR already merged, so maybe that's why I'm not seeing it.

[azc100]

On the Feedback Hub there are no "identifiers". I am attaching an image of the whole thing. I can reproduce the problem at will on my PC. In the Feedback Hub report there is a registration, obtained running "make check" on the vim/src directory, but whatever edit will show the problem.

[azc100]

I tried on my PC with less, and indeed it crashes. I don't know about #13250, it does not seem related (to me). Anyway, the problem actually happens if one edits (with vim) a file that is not empty. Just invoking "vim" (without specifying a file) works fine. The bypass is to use gvim instead... The very first invocation is painfully slow, but the further ones are OK.

[zadjii-msft]

I bet it's under "Condividi", that looks like the "Share" button ☺️

I'm only guessing it's related, because less and vim are using the alternate screen buffer. Both you and OP mention that it seems to crash on the last line, and the bug at the root of #13183 was an off-by-one at the bottom of the alt buffer.

[azc100]

...got it: https://aka.ms/AAh8kuo

[azc100]

If I should test something locally, I will gladly do it.

[zadjii-msft]

Hmm. The windowsterminal.exe dump there doesn't actually have a stack track for an exception or crash - it looks like it was running along just fine. Just to be sure - you repro'd the crash while the Feedback Hub was recording, right?

There's like, 3 OpenConsole's and 6 conhosts there though, so maybe one of them has something? I doubt it though, that crashing wouldn't bring down the Terminal.

[azc100]

Yes, the Feedback Hub was recording. And usually I have an authorized Windows Terminal with 5-6 Ubuntus (one of them, root) and a couple of MS-DOS. I could try to reproduce the problem with just one Ubuntu session, if that can help.

[azc100]

I tried to get a recording using Vim verbose option, but no file was produced at all, Windows Terminal just went away.

[Charlweed]

I used the feedback app, but I don't use a Microsoft account, so Feedback did not give me a URL to paste.

The behavior does not really "look" like a crash, the Terminal window just closes. I imagine it's as if Less is sending a control sequence that Terminal is interpreting as "Close Window"

[azc100]

I agree with Charlweed, in the sense that Windows Terminals closes down, without even worrying about asking the user if it is OK to close all the active sessions. It just shuts down...

[zadjii-msft]

Windows Terminals closes down, without even worrying about asking the user if it is OK to close all the active sessions. It just shuts down.

That sounds like a crash to me 😉

[azc100]

...more like a hara-kiri.

[zadjii-msft]

Hmm. This doesn't repro on the commit before #13250 for me. Lemme do some more bisecting, see if I can even get a repro.

• ✅ 997b4ac - 1.14.1451
• ✅ 1de1325 - the commit before the fix
• ✅ 94e1697 - the commit I think fixes it
• ✅ main

[zadjii-msft]

Okay, I can't repro this even on the 1.14.1451 commit. I might need someone who can repro it to help confirm if 94e1697 fixes it for them.

For folks that are hitting this - Do you have any sort of screen reader running? Narrator, NVDA, JAWS, anything like that? I believe there are other things that try to use the UIA tree, but those are usually the most common

[azc100]

I am not running any software of the above list (Narrator, etc.). I can generate the error (with Vim) very easily, not sure if the Feedback Hub recording could help... If the "hara-kiri" idea holds, one should check when the "close up everything" routine is invoked without a previous prompt for confirmation. If I have to try something locally, I am available.

[azc100]

I reproduced the problem on my PC: see https://aka.ms/AAh8kuo
This time Windows Terminal had only one session running, Ubuntu.

[zadjii-msft]

oh ho ho, there was a stowed XAML exception after all!

Looks like uiautomationcore is loaded into all those processes, so someone is using the UIA tree. Dunno if it's possible to find out who.

=========================
@$xamlstowed()                 : 5 ErrorContexts
    length           : 0x5
    [0x0]            : 0x23ac9bce670 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x1]            : 0x23ac9bcc910 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x2]            : 0x23ac9bd3e90 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x3]            : 0x23ac9bd2130 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]
    [0x4]            : 0x23ac9bd03d0 : 0x80131515 in Windows_UI_Xaml!DirectUI::AutomationPeer::UIATextRangeInvoke+0x1051 [Type: ErrorContext *]

That gives me more confidence that this is the thing that #13250 fixed

[azc100]

I can look into Vim source files, if you tell me what to search for... The only active session under Windows Terminal was Ubuntu (22.04). There was not much else active on the PC, the Feedback Hub, the "cattura e annota" tool, and the usual bunch of system tasks that are usually running (the PC was connected to the Internet).

[zadjii-msft]

Any chances this is a touchscreen laptop? wait nevermind, that ususally triggers TSF, not UIA.

I wouldn't be surprised if the screen capture tool invokes UIA. Magnifier and Cursor Highlighting are two other common tools. Unfortunately, it seems like there's not really a good way to try and figure out what invoked UIA 😕

I'd really doubt this is something specific to vim, I'd bet it's anything that uses the alt buffer.

[azc100]

When will a release of Windows Terminal that does not break using Vim be available? Can I build it locally? It is rather annoying not being able to use Vim, especially since I use it everyday. I am presently forced to call it from MS-DOS or to run it on a real Linux PC... Thanks in advance.

[zadjii-msft]

Hey the fix that I think fixed this shipped in Stable https://github.com/microsoft/terminal/releases/tag/v1.14.1861.0, Preview https://github.com/microsoft/terminal/releases/tag/v1.15.1862.0 - can you confirm that one of the 1.*.186*.0 builds fixes this for you/?

[azc100]

Hi Mike, Sorry for the delay in answering! Yes, the problem is now gone with version 1.15.2003.0 of Windows Terminal Preview (July 26, 2022) (not sure about the git version, I just got it from the Microsoft Store). Thanks for everything! Antonio

[zadjii-msft]

Nice, thanks for confirming!