conpty: Images rendered by imgcat is cut off by cmd.exe or wsl prompts

[nhat-vo]

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20230424-110818-dc2cd706

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

It seems that in Windows, wezterm imgcat is cutoff by the prompt of cmd.exe or in wsl.

To Reproduce

On windows, open wezterm in cmd.exe or wsl. Then run wezterm imgcat on a relatively large image.

Configuration

No config.

Expected Behavior

The prompt should be printed below the image instead of cutting it.

Logs

No response

Anything else?

No response

[wez]

On Windows, ConPTY can swallow or re-order escape sequences that it doesn't understand in a number of situations.
Relevant upstream issues are:

• ConPTY Passthrough mode  microsoft/terminal#1173
• Conpty "pass-through" doesn't maintain order of operations microsoft/terminal#8698
• [1.15+] Flushing FTCS sequences causes flickering in nushell 0.66+ microsoft/terminal#13710

What I suspect is happening here is that, because conpty doesn't understand the iterm2 image protocol, it doesn't know that the cursor position should have moved, and conpty decides to place the cursor position on the next line.

See: https://wezfurlong.org/wezterm/what-is-a-terminal.html#windows-and-conpty for more information about conpty and how it fits into the architecture.

I'd recommend bypassing conpty when using image protocols on windows and using wezterm ssh to connect directly to an ssh server running in your wsl environment.

[nhat-vo]

Thanks for the reply. I am trying to connect using wezterm ssh to the server running in wsl environment, but when I do wezterm imgcat image, it gives me a blank space like this
.

The log give the error

ERROR  wezterm_gui::glyphcache > Unable to move file data to blob manager: Storage has not been initialized

Do you know what might have happened?

[wez]

Ah, yes; that's a bug that I have now fixed, and that will be available to download within the next hour or so.

[wez]

To clarify, that fix will be in a nightly download available from https://wezfurlong.org/wezterm/install/windows.html

[adelarsq]

Hello @wez. I have confirmed that its working on nightly for PowerShell:

For clink shows like this:

I will follow this issue to help on the tests.

[wez]

@adelarsq I just pushed a commit that I think might help with the presentation you saw with clink.

It typically takes about an hour before commits are available as nightly builds for all platforms.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (a .zip file on Windows) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

[adelarsq]

@wez Thanks for looking into that. I did some tests with nightly.

With clink/cmd shows the same behaviour:

But there is some odd behaviour with PowerShell. Calling imgcat on the first line shows like this:

Environment:

• Clink
  • Clink v1.5.1.1e9e51
• PowerShell

Name	Value
PSVersion	7.3.6
PSEdition	Core
GitCommitId	7.3.6
OS	Microsoft Windows 10.0.22621
Platform	Win32NT
PSCompatibleVersions	{1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1
WSManStackVersion	3.0

[wez]

@adelarsq Thanks! Please confirm the wezterm version you're using; open the debug overlay (CTRL-SHIFT-L) and share the version info from there

[wez]

For pwsh, if you scroll up, does the scrollback look correct and fully intact?

[adelarsq]

@wez I have confirmed that its working on my side, on both cmd and powershell.

CMD:

PowerShell:

The reason for the bug was a missconfig on my side, with nightly and current conflicting each other.

[wez]

Thanks for confirming! Let's close this!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.