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.

Sign up for GitHub

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

Jump to bottom

Another case of the virtual bottom being miscalculated #13078

Closed
j4james opened this issue May 10, 2022 · 3 comments · Fixed by #13087
Closed

Another case of the virtual bottom being miscalculated #13078

j4james opened this issue May 10, 2022 · 3 comments · Fixed by #13087
Labels
Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) Impact-Correctness It be wrong. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Conhost For issues in the Console codebase Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal v1.15

Comments

@j4james
Copy link
Collaborator

j4james commented May 10, 2022

Windows Terminal version

Commit ec726e7

Windows build number

10.0.19041.1415

Other Software

vttest

Steps to reproduce

  1. Open a bash shell in conhost.
  2. Immediately run vttest.
  3. Select test 4 (Test of double-sized characters).
  4. Press enter twice until it gets to the 132-column test.

Expected Behavior

It should display a 132-column version of the test output with examples of double width and double height content.

Actual Behavior

The page appears mostly blank, but if you scroll back in the buffer, you can see the test content has rendered on the page above (partially overwriting the previous test). This doesn't seem to happen (at least not consistently) if you've already scrolled down in the buffer when you start the test.

I believe this is another victim of PR #12972. And it looks like the source of the problem is again in the ResizeWithReflow code, which picks a position for the virtual bottom that isn't far enough down. I think this is because the majority of the page is blank at the time of the resize.
@j4james j4james added the Issue-Bug It either shouldn't be doing this or needs an investigation. label May 10, 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 May 10, 2022
@j4james
Copy link
Collaborator Author

j4james commented May 10, 2022

I should add that I have an idea for fixing this: Essentially what we'd need to do is save the distance between the cursor row and the virtual bottom prior to resizing, and then add that distance to the new cursor row after resizing, and that should give us a good estimate of where the new virtual bottom ought to be. We'd still probably also need to take into account the other boundaries that we're currently checking, like the last non-space row, and the viewport height.

If that works, I'll try and put together a PR with the fix on Thursday.

@DHowett
Copy link
Member

DHowett commented May 11, 2022 •
edited
Loading

(FWIW: I don't necessarily think you do, but if you do feel bad about introducing more virtual bottom bugs . . . just think about all the ones we already had that you helped to enumerate and fix(!). In true Windows Console fashion, and in the fashion of every other project everywhere, you can't make an omelet without breaking a few lions eggs. I'm eternally grateful for you breaking those eggs.)

@DHowett DHowett added Product-Conhost For issues in the Console codebase Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) Priority-2 A description (P2) Impact-Correctness It be wrong. labels May 11, 2022
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 11, 2022
@DHowett DHowett added this to the Terminal v1.15 milestone May 11, 2022
@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label May 11, 2022
@j4james j4james mentioned this issue May 12, 2022
Merged
@ghost ghost added the In-PR This issue has a related PR label May 12, 2022
@ghost ghost closed this as completed in #13087 May 12, 2022
@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 May 12, 2022
ghost pushed a commit that referenced this issue May 12, 2022
@j4james
Restore virtual viewport position after resize with reflow (#13087)
c2f8308 
When the buffer is resized with a reflow, we were previously calculating
the new virtual bottom based on the position of last non-space
character. If the viewport was largely blank when resized, this could
result in the new virtual bottom being higher than it should be.

This PR attempts to address that problem by restoring the virtual bottom
to a position that is the same distance from the cursor row as it was
prior to the resize.

This was a regression introduced in PR #12972.

We still take the last non-space row into account when determining the
virtual bottom, because if the content of the screen is forced to wrap,
the virtual bottom will need to be lower (relative to the cursor) than
it was before.

We also need to check that we don't overflow the bottom of the buffer,
which can occur when the viewport is at the bottom of the buffer, and
the cursor position is pushed down as a result of content wrapping above
it.

I've manually confirmed that this fixes the problem reported in issue
#13078, and I've also extended the existing `RefreshWithReflow` unit
test to cover that particular scenario.

Closes #13078
carlos-zamora pushed a commit that referenced this issue May 12, 2022
@j4james @carlos-zamora
Restore virtual viewport position after resize with reflow (#13087)
521d968 
When the buffer is resized with a reflow, we were previously calculating
the new virtual bottom based on the position of last non-space
character. If the viewport was largely blank when resized, this could
result in the new virtual bottom being higher than it should be.

This PR attempts to address that problem by restoring the virtual bottom
to a position that is the same distance from the cursor row as it was
prior to the resize.

This was a regression introduced in PR #12972.

We still take the last non-space row into account when determining the
virtual bottom, because if the content of the screen is forced to wrap,
the virtual bottom will need to be lower (relative to the cursor) than
it was before.

We also need to check that we don't overflow the bottom of the buffer,
which can occur when the viewport is at the bottom of the buffer, and
the cursor position is pushed down as a result of content wrapping above
it.

I've manually confirmed that this fixes the problem reported in issue
#13078, and I've also extended the existing `RefreshWithReflow` unit
test to cover that particular scenario.

Closes #13078

(cherry picked from commit c2f8308)
Service-Card-Id: 81864034
Service-Version: 1.14
@ghost
Copy link

ghost commented May 24, 2022

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

Handy links:

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Output Related to output processing (inserting text into buffer, retrieving buffer text, etc.) Impact-Correctness It be wrong. Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Conhost For issues in the Console codebase Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Milestone
Terminal v1.15
Development

Successfully merging a pull request may close this issue.

Restore virtual viewport position after resize with reflow j4james/terminal
2 participants
@DHowett @j4james