Inconsistent behavior of the Inline Images Protocol

[sxyazi]

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

wezterm 20230712-072601-f4abf8fd

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

No, and I'll explain why below

Describe the bug

Hi, I'm working on a terminal file manager, which is going to add support for the Windows platform, and I've noticed some issues when adapting the image preview for the Windows version of WezTerm:

Before I draw the image I need to move the cursor position to the top left corner of the image start, but on Windows the cursor needs to be shown for this to work:

execute!(stdout, MoveTo(x, y), Show)?;
stdout.write_all(&image_data)?;
execute!(stdout, Hide)?;

Other platforms (I only tested macOS) don't need it:

execute!(stdout, MoveTo(x, y))?;
stdout.write_all(&image_data)?;

Another issue is that I need to clear the old image before drawing the new one, and clearing the image and drawing the new image can break the TUI occasionally.

222.mp4

This issue is not present on macOS, only on Windows. When I comment image_hide, image_show any of them the issue disappears, and it only exists when both are present.

To Reproduce

Below is the ANSI escape code to send for the second issue:

image_hide:

\x1b7        save position
\x1b[1;1H    move 1,1
\x1b[?25h    show cursor
\x1b[2;50H   move 50,2
\x1b[K       kill the line until end
\x1b[3;50H   ...
\x1b[K
\x1b[4;50H
\x1b[K
\x1b[5;50H
\x1b[K
\x1b[6;50H
\x1b[K
\x1b[7;50H
\x1b[K
\x1b[8;50H
\x1b[K
\x1b[9;50H
\x1b[K
\x1b[10;50H
\x1b[K
\x1b[11;50H
\x1b[K
\x1b[12;50H
\x1b[K
\x1b[13;50H
\x1b[K
\x1b[14;50H
\x1b[K
\x1b[15;50H
\x1b[K
\x1b[16;50H
\x1b[K
\x1b[17;50H
\x1b[K
\x1b[18;50H
\x1b[K
\x1b[19;50H
\x1b[K
\x1b[20;50H
\x1b[K
\x1b[21;50H
\x1b[K
\x1b[22;50H
\x1b[K
\x1b[23;50H
\x1b[K
\x1b[24;50H
\x1b[K
\x1b[25;50H
\x1b[K
\x1b[26;50H
\x1b[K
\x1b[27;50H
\x1b[K
\x1b[28;50H
\x1b[K
\x1b[29;50H
\x1b[K
\x1b[30;50H
\x1b[K
\x1b[31;50H
\x1b[K
\x1b[32;50H
\x1b[K
\x1b[33;50H
\x1b[K
\x1b[34;50H
\x1b[K
\x1b[35;50H
\x1b[K
\x1b[36;50H
\x1b[K
\x1b[37;50H
\x1b[K
\x1b[38;50H
\x1b[K
\x1b[39;50H
\x1b[K
\x1b[40;50H
\x1b[K
\x1b[41;50H
\x1b[K
\x1b[42;50H
\x1b[K
\x1b[?25l      hide cursor
\x1b8          restore position


image_show:

\x1b7        save position
\x1b[2;50H   move 50,2
\x1b[?25h    show cursor
\x1b]1337;File=inline=1;size=12325;width=346px;height=230px:/9j/4AAQSkZJ.....RgABAgA2Q==
\x1b[?25l    hide cursor
\x1b8        restore position

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

I've tried using the nightly version, but I can't get it to run on my Windows 11.

[wez]

See:

• wezterm imgcat with vifm #2902 (comment)

This isn't a wezterm issue, it's a ConPTY issue.

See https://wezfurlong.org/wezterm/what-is-a-terminal.html#windows-and-conpty for more information on ConPTY and it's relationship with terminal applications.

[sxyazi]

Thanks for the reply, but it doesn't seem to make sense to me.

In my first issue, the cursor must be shown before drawing the image and then hidden, is this a Windows-specific behavior or is it an exception to the expected behavior due to ConPty?

I'm not sure if this is due to ConPty or not, because after two days of debugging, I found a workaround that allows the image to be displayed properly, but doesn't break the tui, which is that it must perform the clear immediately before the image is rendered, and can't put clearing, and rendering in two separate steps. This may sound trick, but it works, and not sure there's a better way at this point.

[wez]

Please read the comment I linked to carefully; it in turn links to a number of other open conpty issues that are relevant:
microsoft/terminal#8698 is most likely the root cause.

[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.