New tab in Windows Terminal is missing content

[konnorandrews]

Windows Terminal version

1.17.11461.0

Windows build number

10.0.22621

Other Software

rustup - all versions including newest https://rustup.rs/

Steps to reproduce

See rust-lang/rustup#3430 for reproduction steps.

Expected Behavior

rustup's installer has a setup menu it prints. This should be displayed when rustup-init.exe is run.

Example shown below is when rebuilding the rustup-init.exe binary to wait 5 seconds before outputting anything.

Actual Behavior

The menu does not appear and the content seems to be duplicated on top of it. Scrolling only shows a blank section at the top of the buffer.

[konnorandrews]

This seems to happen only when a new tab/window is created. If I run rustup-init.exe from a powershell instance in Windows Terminal it works as expected.

[zadjii-msft]

I bet this is #14512. Can you try Terminal Preview (v1.18), and set that as your Default Terminal, and try again/?

[ryanavella]

I can confirm that the problem is not reproducible with Terminal Preview (v1.18).

Given that the rustup folks would probably like a workaround for v1.17 and earlier, is there a straightforward way for an application to detect the version of Windows Terminal it was spawned from?

[ryanavella]

Also I am struggling to find information on the usual release cycle for Terminal, any idea when 1.18 will be stabilized?

[zadjii-msft]

I honestly wouldn't bother with a workaround for earlier versions. I'm not even sure there is one based off the way the bug manifested. It was a race between the terminal's size and the conpty size, but I'm not even sure that introducing a forced delay before emitting text would always fix this.

I think there was some discussion about servicing that back to 1.17, lemme necro that thread quick.

We've kinda moved to a quarterly ship cycle, so we're starting to button up 1.19 now. I'd guess that 1.18 becomes stable in about a month?

Ultimately, if it were my call, I'd say that this isn't worth the engineering effort to waorkaround, when there's a fix in hand that's just "update to a newer Terminal version". Which should happen automatically for most folks in a month.

[ryanavella]

The reason some want a workaround is that it is fundamentally an accessibility issue. We want to be able to tell Windows users, who have no prior programming experience, "just run rustup-init.exe and you are good to go." But instead some are coming to forums and chat servers and saying Rust isn't working after installing it (note: when the installer menu is trimmed to the first 30 lines, it looks as though it installed successfully)

So if there isn't a workaround for detecting the terminal version, that probably limits us to either a delay-based workaround, or adding an extra installation step to install Windows Terminal Preview. I'm fine with either, I'd just like to better understand our options.

[microsoft-github-policy-service]

This issue has been marked as duplicate and has not had any activity for 1 day. It will be closed for housekeeping purposes.

[zadjii-msft]

We discussed this a bit in team sync today - @DHowett is just going to cut a servicing release of 1.17 that includes that fix. Honestly, that's just the easiest solution here. There's literally no reason for y'all to waste engineering cycles trying to work around an already fixed bug. And it would probably be a collective lot of engineering effort.

Easier to just push an update to the Store 😉

[zadjii-msft]

(to close the loop - Terminal 1.18 stable is out now, with the aforementioned fix)