Open ssbssa opened 1 year ago
Thanks for the repro!
This change in behavior is almost certainly a result of PR #12972, and I suspect it could be difficult to resolve without reintroducing the virtual bottom bugs that PR was attempting to fix.
Thanks for putting this issue down. I have the same issue and it really sucks, as there's no other API that can perform the functions with GetConsoleScreenBufferInfo() in the meantime. CONSOLE_SCREEN_BUFFER_INFO::dwCursorPosition.Y is also affected by this, and it maxes out at the vertical console window size when you hit the bottom of the console window to the point where the scrollbar shows up.
Any updates on the bug? I was able to create a custom detection algorithm for the bug, maybe that helps:
// A function to check for a specific bug affecting CONSOLE_SCREEN_BUFFER_INFO::dwCursorPosition
// positioning reports, in the new Windows Terminal and OpenConsole.exe.
bool ConsoleWTBugCheck() {
// Get console size
HANDLE hTest = GetStdHandle(STD_OUTPUT_HANDLE);
CONSOLE_SCREEN_BUFFER_INFO csbiTest;
GetConsoleScreenBufferInfo(hTest, &csbiTest);
int nConsoleHeight = csbiTest.srWindow.Bottom - csbiTest.srWindow.Top;
// Spam enters until a few more than console bottom
for (int i = 0; i <= (nConsoleHeight + 4); i++) {
std::cout << '\n';
}
// Get the console cursor position after that
GetConsoleScreenBufferInfo(hTest, &csbiTest);
int nVerticalCPosition = csbiTest.dwCursorPosition.Y;
cls();
if (nVerticalCPosition <= nConsoleHeight) {
return true;
}
else {
return false;
}
}
This code gets the height of the terminal and spams newlines after at least 1 above the terminal height (i used 4 for some reason). The number of newlines entered is recorded. It then checks the new reported height by the GetConsoleScreenBufferInfo() function. If that function reports anything smaller than the number of newlines entered, then the bug is there, else it isn't. A cls() function is there to clear the screen after the newlines so the user doesn't see them.
It is required that the test is done when the cursor position is at the highest row (0).
Windows Terminal version
1.16.230126001
Windows build number
10.0.19044.2486
Other Software
No response
Steps to reproduce
I mentioned this first in #14759.
You can reproduce the problem with this test program:
There is a difference of behavior when tried with either the conhost.exe of the current Win10, or the OpenConsole.exe of Microsoft.WindowsTerminal_Win10_1.16.10261.0_8wekyb3d8bbwe.msixbundle.
Between entering some keys, scroll the window up or down with the mouse.
Expected Behavior
Once you enter a key, and the cursor position is re-set, it will scroll the window to the cursor, but only if the cursor was not already in the visible part of the window. Which is exactly how it works in conhost.exe.
Actual Behavior
But with OpenConsole.exe 1.16.230126001, the window is always scrolled so that the cursor is at the bottom of the screen, even if it was already visible before.