ESC key press in CMD prompt

[luke1961]

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):

Any other software?

Steps to reproduce

Expected behavior

Actual behavior

[luke1961]

Environment:
Win32NT 10.0.18363.0 Microsoft Windows NT 10.0.18363.0
Conhost 10.0.18362.1

The problem is in pseudoconsole output when ESC key is pressed while running CMD.EXE.
Steps to reproduce:

1. Programmatically set up Terminal to operate as a pseudoconsole, launch CMD.EXE
2. Run and then exit (for example by pressing F10) Far Manager, version 2.0 (build 1807) x86. This step is critically important
3. Type a number of characters in the command prompt
4. Press ESC key
5. You expect the characters to be erased and cursor come back to the beginning of line
   but the cursor does not come back even though the characters are erased.
   Here is my trace:

Ignore the dashed lines, they separate the reads from pseudoconsole's output pipe. I typed 'j' 4 times and then pressed ESC. I see that after ESC is pressed the cursor is positioned at the right spot by ESC[26;5H but then spaces are sent to erase text. Unfortunately the spaces move the cursor.

Any ideas? Maybe something to do with console mode flags?

[luke1961]

Here is how the screen looks after ESC is pressed, chars erased but cursor in the wrong spot

[DHowett-MSFT]

It's really interesting that this only happens after FAR manager's been launched.

[luke1961]

Also, I see that as soon as I type a char the cursor positioning escape sequence is sent. I have rebuilt OpenSSH (because it also uses pseudoconsole) with some trace code and the same behavior occurs. Almost looks like FAR Manager 'did something' to the pseusoconsole that makes it not flush all of its output.

[zadjii-msft]

Unfortunately I'm not seeing this on the 10.0.19601.1000 DEP build I'm on. @DHowett-MSFT can you try and repro this on 19H2 compared with 20H1?

Maybe this has to do with our weird newBottomLine handling, that coincidentally might be getting much better as we speak

[jdebp]

It's interesting that 5 SPC characters are sent in order to blank out 4 j characters. Is your buffer differencing sensitive to where the cursor is? And shouldn't you be setting DECTCEM high after all of the update output? You seem, if I am understanding that trace correctly, to be setting it high before the final j character of those updates was output.

[zadjii-msft]

The whole trace looks like it's from a pretty old version of conpty tbh. There's a lot of optimizations we've done to emit less text, but I can't really recall what timeframe those were done in exactly.

There's clearly some bug that's happening here, but I'm 🤞 that this was actually already fixed ☺️

[luke1961]

I have installed Windows Terminal. Is there a way to force CreatePseudoConsole to use it instead of the old conhost which is on my system. maybe you can point me to a link about how to make it happen. It appears I have created a bug report for something which is in the rear view mirror for a while.

[zadjii-msft]

I'm not sure there's really a recommended way at the moment unfortunately. This has been a pain area we've been thinking of solutions for actively, but don't have a definitive plan for quite yet. @DHowett-MSFT might have some ideas for workarounds for you

[DHowett-MSFT]

Does this specifically require far 2.0? I just (accidentally) tried it with Far 3.0.

Here's my results:

version	status
rs3 (16299)	❌ there is no conpty
rs4 (17134)	✔️ cursor moves home
rs5 (17763)	✔️ cursor moves home
19h1 (18362)	✔️ cursor moves home
vb (19041)	✔️ cursor moves home
xx (unreleased)	✔️ cursor moves home

(also cool: this)

[luke1961]

Just tried with 'Far Manager, version 3.0.0.5555 x64' and the problem does NOT occur. It looks like it requires 'Far Manager, version 2.0 (build 1807) x86'. Do you have this version? I can easily zip my 'far 2.0' folder and attach it. Thank you for being persistent on this problem report. I am not married to 'far 2.0' in any way, just like it because it provides a good testing 'exercise' for my projects involving Windows Terminal.

[luke1961]

Also, I was able to duplicate the problem using your VtPipeTerm tool. Options:

--debug --conpty --headless

I launched 'far 2.0', pressed F10 to terminate, got back into the command line, typed a couple of chars, pressed ESC and the cursor failed to return where it should.

conhost version: 6.3.18362.1
process tree:

[zadjii-msft]

I'm tempted to resolve this as external considering that this has always worked for Far 3.0, and only doesn't work in Far 2.0. I suppose we could try and take a look at what we're doing wrong in the Far 2.0 case, but I'm definitely inclined to endorse the workaround of "upgrade Far".

I'll let @DHowett-MSFT make the final call on this one

[DHowett-MSFT]

Okay, this is because FAR 2.0 turns off the display of the cursor. There's two issues here:

1. When ConPTY believes the cursor is "hidden", it switches into a lazy updating mode. Since the user can't see it, it doesn't matter where it is.
2. Until Render the cursor state to VT #2829 landed, ConPTY wouldn't tell the terminal that the cursor was hidden. This made the trickery we were doing in (1) very obvious and visible.

It's Far's job to restore the cursor state when it exits, and with #2829 merged ConPTY will now do the more correct thing (hide the cursor). 😄

Thanks!

[luke1961]

Thanks! Problem solved, I see the issue doesn't show in the latest build of the Terminal when I force VtPipeTerm to use the latest OpenConsole exceutable.