Random letters are inserted on startup

[ricardohavranek]

When opening edit over ssh session, the first line shows this encoding pattern: c/0000cccc/cccc/ccccd6d6/d6d6

Repro steps:
Enable SSH on Windows machine.
Connect to ssh session.
Download and install edit
Run edit

Observed results:
When opened the line number column is shifted 1 char to the right and some kind of encoding string is presented: c/0000cccc/cccc/ccccd6d6/d6d6.

Expected results:
edit should run without issues under a standard ssh session.

[ricardohavranek]

Some other misalignment issues are also observable under ssh session:"

[rhubarb-geek-nz]

Can you clarify how you are using ssh?

Does the behaviour occur in all configurations?

Does using conhost make a difference in comparison to Windows Terminal?

• Windows SSH client to Windows SSHD server
• Windows SSH client to Linux SSHD server
• Linux SSH client to Windows SSHD server
• Linux SSH client to Linux SSH server

[lhecker]

The encoding string is the initial OSC 4 and OSC 10 request (request the color palette / theme from the terminal). This indicates that parts of the response are dropped before they arrive in Edit. However, the output also looks like there are bits being dropped, which is worrying.

I loosely remember working on an issue like this for Windows Terminal a year ago or something. Can you check what version of Windows Terminal you're using? Click on the drop-down menu for the profile and then open the About dialog.

[matsmcp]

Also please include ssh versions.
I have not seen this issue running from conhost. (since windows terminal isn't supported on ltsc2019 I can't test that)

[grochoge]

This appears to be a similar/the same issue I'm seeing with docker in #377.
I didn't see this issue until after I created that; I can close if we'd rather track it here.

This is happening with Windows Terminal 1.22.11141.0; it does not happen with conhost.

[lhecker]

Seems related: PowerShell/Win32-OpenSSH#2275

[lhecker]

[...] it does not happen with conhost.

FYI: The reason this doesn't happen with conhost is most likely because it doesn't support those OSC sequences to begin with.

What I suspect all of these cases have in common is that they're using older versions of ConPTY. ConPTY was not particularly robust until somewhat recently.

Edit: Thinking about this more, inefficiencies in ConPTY and SSH (similar to PowerShell/openssh-portable#771) could be stacking up to lead to an increased latency. We should try bumping up the ESC timeout from 50ms to 100ms and see if that fixes it.

[grochoge]

The issue running through Docker still persists in 1.2

Sometimes the "1" will show up in the proper place in addition to the upper right (but it still has the c0c inserted).

[ricardohavranek]

Can you clarify how you are using ssh?

Does the behaviour occur in all configurations?

Does using conhost make a difference in comparison to Windows Terminal?

• Windows SSH client to Windows SSHD server
• Windows SSH client to Linux SSHD server
• Linux SSH client to Windows SSHD server
• Linux SSH client to Linux SSH server

Using native SSH server and clients from Windows.

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Happens when using native OpenSSH client from Windows to Windows. Version (9.5.4.1) No difference from connhost vs Windows Terminal when using native ssh.exe.

Do not happen when connecting from Linux SSH client or Windows Putty client to Windows SSH Server.