Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After clearing the screen (cls command) and then scrolling up, results in the last line of the previous screen still visible #13320

Closed
egvijayanand opened this issue Jun 17, 2022 · 4 comments · Fixed by #13324
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@egvijayanand
Copy link

egvijayanand commented Jun 17, 2022

Windows Terminal version

1.13.11432.0

Windows build number

10.0.22000.739

Other Software

No response

Steps to reproduce

  1. Open Terminal
  2. Navigate to C:\Windows\System32, a folder where files are available in large numbers so that results occupy an almost available screen space
  3. First run the dir command so that Terminal is made use of
  4. Now clear the screen using the cls command
  5. Now try to scroll up, the last line of the previous screen is still visible

Expected Behavior

When cleared nothing should be visible from the previous result.

Actual Behavior

When scrolled upwards, the last line is still visible even after clearing the results.

@egvijayanand egvijayanand added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Jun 17, 2022
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jun 17, 2022
@egvijayanand egvijayanand changed the title After clearing the screen (cls command) and then scrolling results in the last line of the previous screen still visible After clearing the screen (cls command) and then scrolling up, results in the last line of the previous screen still visible Jun 17, 2022
@j4james
Copy link
Collaborator

j4james commented Jun 18, 2022

I suspect this might be the same problem as #5770.

@egvijayanand
Copy link
Author

Same behavior in PowerShell tab too.

DHowett pushed a commit that referenced this issue Jun 20, 2022
## Summary of the Pull Request

When you execute a `cls` in the cmd shell, or `Clear-Host` in
PowerShell, we have a pair of shims that attempt to detect those
operations and forward an `ED3` sequence to conpty to clear the
scrollback.

If there was a linefeed at the bottom of the viewport immediately 
prior to those functions being called, that event might still be
pending, and only forwarded to conpty after the `ED3`. The result
then is a line pushed into the scrollback that shouldn't be there.

This PR tries to avoid that situation by forcing the renderer to
flush before the `ED3` sequence is sent.

## References

The `cls` and `Clear-Host` shims were originally added in PR #5627.

## PR Checklist
* [x] Closes #5770
* [x] Closes #13320
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #xxx

## Validation Steps Performed

I've manually tested in PowerShell with `echo Hello; Clear-Host` (this
is the only way I could reliably reproduce the original problem), and in
the cmd shell with `cls`. Both cases are now working as expected.
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Jun 20, 2022
DHowett pushed a commit that referenced this issue Jun 30, 2022
## Summary of the Pull Request

When you execute a `cls` in the cmd shell, or `Clear-Host` in
PowerShell, we have a pair of shims that attempt to detect those
operations and forward an `ED3` sequence to conpty to clear the
scrollback.

If there was a linefeed at the bottom of the viewport immediately
prior to those functions being called, that event might still be
pending, and only forwarded to conpty after the `ED3`. The result
then is a line pushed into the scrollback that shouldn't be there.

This PR tries to avoid that situation by forcing the renderer to
flush before the `ED3` sequence is sent.

## References

The `cls` and `Clear-Host` shims were originally added in PR #5627.

## PR Checklist
* [x] Closes #5770
* [x] Closes #13320
* [x] CLA signed.
* [ ] Tests added/passed
* [ ] Documentation updated.
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not
checked, I'm ready to accept this work might be rejected in favor of a
different grand plan. Issue number where discussion took place: #xxx

## Validation Steps Performed

I've manually tested in PowerShell with `echo Hello; Clear-Host` (this
is the only way I could reliably reproduce the original problem), and in
the cmd shell with `cls`. Both cases are now working as expected.

(cherry picked from commit 08c2f35)
Service-Card-Id: 83388911
Service-Version: 1.14
@ghost
Copy link

ghost commented Jul 6, 2022

🎉This issue was addressed in #13324, which has now been successfully released as Windows Terminal v1.14.186.:tada:

Handy links:

@ghost
Copy link

ghost commented Jul 6, 2022

🎉This issue was addressed in #13324, which has now been successfully released as Windows Terminal Preview v1.15.186.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants