[win] window size change not respected in Windows Terminal

[Saviq]

When running multipass shell in the upcoming Windows Terminal, changing the window size often results in a broken console setup.

Easiest to see with byobu, which fills the whole screen.

[marcodelapierre]

I am experiencing a similar issue on macOS Catalina

[Saviq]

Hi @marcodelapierre, we've just fixed this in #1354, can you please try the release candidate from #1375 (comment) - if that doesn't help, please file a separate issue. Thanks!

[marcodelapierre]

thanks @Saviq , just tested, my terminal resizing issue was fixed!

[townsend2010]

Boo, console WinEvents are not being used in the new Windows Terminal. Will have to investigate what API it is using and see if there is some way to hook into it.

[townsend2010]

Seems we're going to have to redo how we detect window size changes: microsoft/terminal#1811

[ricab]

Yeah I was planning to take a look as part of the work to integrate on the windows terminal.

[ricab]

I've been investigating this and here are a few conclusions.

WT supports built-in resize events. These WINDOW_BUFFER_SIZE_EVENTs really should be triggered whenever the viewport is resized. IIUC, these "events" can only be obtained from the buffer itself, mixed with the rest of the input, via ReadConsoleInput or PeekConsoleInput. However, we use ReadConsole to get the text, which discards those events. We also use a flush, whose purpose isn't clear to me.

Changing the code to peek into the input events before reading or flushing, I could get the resize ones. However, reacting to a resize there means only updating when there is input. Doing it elsewhere risks loosing the events. I tried that when writing and in a separate thread that would peek periodically and they both missed the events.

So, that did not seem very feasible. We'd have to change the way we do input reading and perhaps make it asynchronous with ssh comm...

What did work quite well was to ignore the event entirely and just check periodically whether the size had changed (in a separate thread). Timing this, each check took a few microsecond and had no usability impact. Doing it twice per second felt nice to me with both byobu and mc. There is only a tiny delay before the resize is rendered (at most as much as the chosen period).

Alternatively, while WT does not support MSAA events (as @townsend2010 found out), it should support UIA, even though they don't guarantee anything if you're not attempting to use them for [accessibility] purposes. I did not explore this avenue yet.

[ricab]

I think I've got something working without any extra thread or accessibility extra 🤞