Command History on wrong line

[nurbles]

Environment

Windows build number: 10.0.19041.329
Windows Terminal version (if applicable): 1.0.1401.0

Any other software? no

Steps to reproduce

Cannot reproduce on demand, but I know it occurred after dragging the window to a new size (number of rows and columns.)

Expected behavior

I was in a Command Prompt, using the Up Arrow to recall my command history.
I expected the recalled commands to appear on the current command line.

Actual behavior

The FIRST command recalled appeared on the current command line, subsequently recalled commands (I pressed Up Arrow more than once) appeared one row above but indented as if after a prompt (though the line above was previously blank.)

FWIW, this is not the first issue I've seen after resizing the window, but almost all of them go away after another resize and do not return if I try to return to the previous size and test for them. So the triggers are difficult to define, sorry. Hopefully this will at least warrant some comments near where this is handled, just in case something is noticed in the code. :-)

[zadjii-msft]

Uhg, I see this every so often, and it drives me mad. I was hoping that I had sorted most of this out in #4200, but I definitely missed something. It's a shame that this is so horribly hard to repro.

Gonna toss this in with the rest over at #5800

[nurbles]

FWIW, this just happened to me again and there was no window resizing involved. I have a CMD script that updates the test copies of the software I'm working on that emits 5 lines, does a PAUSE, then emits 17 more. My process is to stop my software, run the script and restart my software (which is actually loaded by a small Windows program that I start from the command line -- nothing of mine is a command line program.) After having down that a few times, enough to cause the window to scroll, the behavior I originally described occurs.

The terminal window HAD been MOVED but not resized at the time I saw this today.

So, I may be able to trigger this on demand, if there is anything I can do to help debug/test this, please let me know.

[mda000]

I do see something very similar to this with no resizing involved. The last couple of lines at the bottom of the terminal can become unavailable for input, and input is overdrawn one or two lines above. It happens randomly, but only rarely--a couple of time a week for me. I have not been able to reproduce the problem.

I'm more than happy to create a minidump or perform other debugging when I see this.

[nurbles]

[using 1.0.1401.0] Not sure this is related but I just rebooted and used a Command Prompt tab to restore three network drives by doing "dir P:" (and Q: and R: if it matters). This, of course, caused the text in the tab to scroll for at least a few pages. I then started to enter another command and pressed ESCAPE to erase it. Instead of being erased, the input cursor jumped to just after my prompt ON THE PREVIOUS LINE. Once this happened, it happened any time I used escape to erase a command. Unfortunately, after restarting the terminal program and opening a new Command Prompt tab I was, of course, unable to get it to happen again.

Are there instructions for capturing anything useful that I can follow if I see this happening again?

[fsigalov]

I have a related repaint issue, if I go into history of command, then use left arrow to go back into it and edit it. It does edit, but the repaint is very weird.

[jingyu9575]

Hi, I also frequently see this problem. Here are some information I know:

• On my system when the bug happens, the text always appears 2 lines above. My pwsh prompt is 3 lines (\n 21:07 D:\Desktop WINDOWS-2G64 \n -)

• It is always at the bottom of the terminal window.
• In this screenshot, there is no scrollbar before the bug occurs. After the bug occurs, if I scroll back to the top, the text will be at the bottom of the terminal, where the prompt - should be. Maybe there are some race conditions about the scrolling?
• I then tried the mode command which I think affects the scrolling. It seems that repeatly running it triggers this:

In this screenshot, the text is at the 3rd line (2 lines lower). If I scroll back to the top, it is exactly where the prompt - should be. It seems to be the reverse problem of the original issue.

[DHowett]

Using mode to set the console window size is going to corrupt your Terminal buffer. You may have noticed that it doesn't actually resize the window 😄

[KirillOsenkov]

Once it gets into this state it's pretty corrupted:

[KirillOsenkov]

I just reproduced this again.

This is how it looked like:

I typed msbuild /r /m /bl *.sln when the prompt was in the last row, then pressed Tab to complete, and the moment it completed it completed on the line above.

[KirillOsenkov]

I just tried this exact sequence again and it didn't repro :(

[KirillOsenkov]

I just noticed that when the caret is dangerously close to the bottom of the screen it sometimes scrolls one line up to bring the caret up further away from the bottom edge, and that scroll happens almost simultaneously with text output.

Is there a lock around that scroll action and the text output? Certainly feels like a race condition where something is not transactional and side effects from scrolling and output are observed before an operation completes.

I'm just speculating of course since I haven't debugged or even looked at the code.

[KirillOsenkov]

Could we consider bumping the priority on this please? Surprised that corruption and inconsistency of core internal data structures is prioritized as P3. The core data structures should be rock solid and we should do tons of stress testing and fuzzing to catch these issues.

@zadjii-msft @DHowett

[KirillOsenkov]

Just hit this in the opposite direction with Tab completion, and there was no scrolling involved as the prompt was roughly in the center of the screen:

[zadjii-msft]

Hooplah, a consistent repro from #9897

Steps to reproduce:

1. Open Terminal (PowerShell)
2. Push Enter enough times to get to the bottom of the window
3. Enter line long enough so it will get broken when window is resized horizontally
4. Move cursor backwards and enter a different character to mark your position
5. Resize the window horizontally.
6. When the line gets broken and text scrolls up observe that the cursor is not where it should be

Old console doesn't have this issue.

cmd.exe in Terminal app has a similar issue

I'll add that I remove-module psreadline's first

[zzsergant]

Is there any news about this issue or ETA on fix?
I mean, this issue created almost year ago and there are multiple ways to reproduce it. Isn't this a high priority bug?

For me that issue ruining terminal usage experience every day, when it garbage the output and I need to do the resize window workaround and re-run the command again.

[zadjii-msft]

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

[KirillOsenkov]

Continuing to see weirdness and race conditions:

[zadjii-msft]

terminal vs pty. Doesn't seem like #5368 affects this

though, same thing in just conhost:

OH BUT INTERESTING.

If you set conhost's buffer to be the same size as the viewport, then it'll repro exactly the same. Furthermore, same will happen with conhost+cmd.exe+buffer.size=viewport.size

[zadjii-msft]

Okay I'm getting too into the weeds here I think. These feel like issues that'll just go away with #8000. There's weirdness going on where it seems like the TextBuffer circled once to leave a space for this line where the cursor should be, but the cursor is actually at the start of the prompt (and the prompt isn't in the buffer during the resize). So it ends up redrawing itself where it was, which is now a blank line. But that blank line should have never existed!

[zadjii-msft]

      // There is a special case here. If the row has a "wrap"
        // flag on it, but the right isn't equal to the width (one
        // index past the final valid index in the row) then there
        // were a bunch trailing of spaces in the row.
        // (But the measuring functions for each row Left/Right do
        // not count spaces as "displayable" so they're not
        // included.)
        // As such, adjust the "right" to be the width of the row
        // to capture all these spaces
        if (row.WasWrapForced())

We're hitting the case where the last row of the buffer thinks it was wrapped, so we fill all the spaces into the new buffer. But that's not really the case! The commandline was hidden, so that line shouldn't be marked as wrapped!

EDIT:

But, this makes me think that this particular repro isn't the same root cause as the other bugs. This is just the Commandline/cooked read failing to unmark a line as wrapped in one very particular scenario. This is far too specific to be relevant to the plethora of other examples here (despite not having consistent repros for those).

[alrz]

This issue is kind of came back. I'm using preview 1.21.1772.0, just using a curl with a long url and making edits in the middle and hitting enter doesn't exactly send the same command as seen in history with the up key.

[lhecker]

@alrz Could you open a new issue for this? It'd be especially nice if you had a repro case for us.