CLS should reset the virtual viewport bottom #13516

Closed
opened 2026-01-31 03:44:45 +00:00 by claunia · 1 comment
Owner

Originally created by @j4james on GitHub (Apr 17, 2021).

Windows Terminal version (or Windows build number)

74909c0c65

Other Software

No response

Steps to reproduce

  1. Make sure you're using a build with PR #9770 merged.
  2. Open a conhost cmd shell.
  3. Output some content to fill a few pages of the buffer.
  4. Execute cls.

Expected Behavior

The buffer should be cleared and the viewport should be moved back to the top of the buffer.

Actual Behavior

The buffer is cleared, but the viewport remains where it was before the cls.

I'm afraid I broke this with PR #9770. Previously cls would have reset the virtual bottom when it reset the viewport, but it doesn't do that anymore. And I suspect there are probably more cases like this.

I'm really not sure what the right solution is though - maybe every viewport change made through the console API should reset the virtual bottom? But whatever we do, there are going to be some cases that behave weirdly - I think that's inevitable when you're mixing the legacy APIs with VT.

For now, though, I think it might be a good idea to revert #9770, because this bug seems a lot worse than #9754.

Originally created by @j4james on GitHub (Apr 17, 2021). ### Windows Terminal version (or Windows build number) 74909c0c6511787907a6a369c8046c11ee373ae8 ### Other Software _No response_ ### Steps to reproduce 1. Make sure you're using a build with PR #9770 merged. 2. Open a conhost cmd shell. 3. Output some content to fill a few pages of the buffer. 4. Execute `cls`. ### Expected Behavior The buffer should be cleared and the viewport should be moved back to the top of the buffer. ### Actual Behavior The buffer is cleared, but the viewport remains where it was before the `cls`. I'm afraid I broke this with PR #9770. Previously `cls` would have reset the virtual bottom when it reset the viewport, but it doesn't do that anymore. And I suspect there are probably more cases like this. I'm really not sure what the right solution is though - maybe every viewport change made through the console API should reset the virtual bottom? But whatever we do, there are going to be some cases that behave weirdly - I think that's inevitable when you're mixing the legacy APIs with VT. For now, though, I think it might be a good idea to revert #9770, because this bug seems a lot worse than #9754.
claunia added the Product-ConhostNeeds-TriageArea-VTNeeds-Tag-Fix labels 2026-01-31 03:44:45 +00:00
Author
Owner

@DHowett commented on GitHub (Apr 28, 2021):

For now, though, I think it might be a good idea to revert #9770, because this bug seems a lot worse than #9754.

Thanks for this. Sorry for the delay here -- we're getting to the end of a Windows dev cycle and by now you've probably guessed that that tends to eclipse the sun. 😄

I'll revert 9770 on main.

@DHowett commented on GitHub (Apr 28, 2021): > For now, though, I think it might be a good idea to revert #9770, because this bug seems a lot worse than #9754. Thanks for this. Sorry for the delay here -- we're getting to the end of a Windows dev cycle and by now you've probably guessed that that tends to eclipse the sun. :smile: I'll revert 9770 on main.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13516