regression post 1.21: TUI app cursor position blocked until a key is hit - was working fine before

[ldemailly]

Windows Terminal version

1.22+

Windows build number

10.0.26100.3775

Other Software

golang 1.23.8
fortio.org/terminal/fps 0.29.2

Steps to reproduce

install golang

go run fortio.org/terminal/fps@v0.29.2 -truecolor

Expected Behavior

Used to work fine as in run continuously

Actual Behavior

Now runs in stop motion where you need to hit a key for next frame(s) to show up

[ldemailly]

I am the author of fps so happy to explain how it works and/or make changes to it for it to become more "windows friendly" - for instance batching didn't work in 1.21 terminal (yet the fps was high/working) and dynamic resize doesn't work unlike in macos/linux

[DHowett]

Interesting... I wonder if it has the same kinetics as #18225. Does it suddenly start working after, say, 65 seconds?

Also, thanks for the report! 1.22 is the first release which uses the new "passthrough" console hosting subsystem (which employs either direct translation (for windows console APIs) or direct passthrough (for already-VT-encoded text), rather than a screen-based readout), so I am not terribly surprised that it's uncovered something.

[ldemailly]

Does it suddenly start working after, say, 65 seconds?

Nah it's just stuck indefinitely - it's possibly a bug in the way I read the input, in 1.21 stdin is non blocking while now it seems blocking (maybe I need to make it non blocking ?)

This is is with

go run fortio.org/terminal/brick@latest

It only moves if I hit a key

[lhecker]

This could either be an issue with how we signal input availability in conhost/ConPTY, or I made a mistake with the overlapped IO signaling.

If you could shrink the repro to a small Go snippet that only reads from stdin (i.e. as little stdout as possible), I'd greatly appreciate it. This is because it would make debug tracing a lot less noisy.

[ldemailly]

Done :)

go run github.com/ldemailly/go-scratch/windows_terminal_issue@v0.2.0

https://github.com/ldemailly/go-scratch/blob/main/windows_terminal_issue/issue18800.go

// https://github.com/microsoft/terminal/issues/18800

package main

import (
	"fmt"
	"os"
	"strings"

	"golang.org/x/term"
)

func RawPrintln(stuff ...any) {
	fmt.Print(stuff...)
	fmt.Print("\r\n")
}

func main() {
	fd := int(os.Stdin.Fd())
	oldState, err := term.MakeRaw(fd)
	if err != nil {
		fmt.Println("Error setting terminal to raw mode:", err)
		return
	}
	defer func() {
		err = term.Restore(fd, oldState)
		fmt.Println("Terminal restored to original , err", err)
	}()
	RawPrintln("Terminal in raw mode - 'q' to exit")
	buf := make([]byte, 16) // fits ansi arrow escape, unicode, etc
	iter := 1
	requestCursorPos := []byte("\033[6n")
	expected := len(requestCursorPos)
	for {
		nw, err := os.Stdout.Write([]byte(requestCursorPos))
		if err != nil {
			RawPrintln("Error writing to terminal:", err)
			return
		}
		if nw != expected {
			RawPrintln("Short write", nw, "vs", expected)
		}
		n, err := os.Stdin.Read(buf)
		if err != nil {
			RawPrintln("Error reading from terminal:", err)
			return
		}
		bufStr := string(buf[:n])
		// might fail with some ansi echo having a q in them,
		// but this is just a quick repro/test.
		if strings.ContainsRune(bufStr, 'q') {
			RawPrintln("\r\nExiting...")
			break
		}
		fmt.Printf("\r[%05d] Read %d bytes: %q      ", iter, n, bufStr)
		iter++
	}
}

The issue is requesting cursor position stops working after a bit on 1.22+ and then resumes working for a little bit when hitting a key

edit: typo corrected and a few fixes, also catch (unlikely/that's not the issue) short writes