Commit 12d2e17
Correct the boundaries of the scrolling commands (microsoft#2505)
There are a number of VT escape sequences that rely on the `ScrollRegion`
function to scroll the viewport (RI, DL, IL, SU, SD, ICH, and DCH) , and all of
them have got the clipping rect or scroll boundaries wrong in some way,
resulting in content being scrolled off the screen that should have been
clipped, revealed areas not being correctly filled, or parts of the screen not
being moved that should have been. This PR attempts to fix all of those issues.
The `ScrollRegion` function is what ultimately handles the scrolling, but it's
typically called via the `ApiRoutines::ScrollConsoleScreenBufferWImpl` method,
and it's the callers of that method that have needed correcting.
One "mistake" that many of these operations made, was in setting a clipping
rect that was different from the scrolling rect. This should never have been
necessary, since the area being scrolled is also the boundary into which the
content needs to be clipped, so the easiest thing to do is just use the same
rect for both parameters.
Another common mistake was in clipping the horizontal boundaries to the width
of the viewport. But it's really the buffer width that represents the active
width of the screen - the viewport width and offset are merely a window on that
active area. As such, the viewport should only be used to clip vertically - the
horizontal extent should typically be the full buffer width.
On that note, there is really no need to actually calculate the buffer width
when we want to set any of the scrolling parameters to that width. The
`ScrollRegion` function already takes care of clipping everything within the
buffer boundary, so we can simply set the `Left` of the rect to `0` and the
`Right` to `SHORT_MAX`.
More details on individual commands:
* RI (the `DoSrvPrivateReverseLineFeed` function)
This now uses a single rect for both the scroll region and clipping boundary,
and the width is set to `SHORT_MAX` to cover the full buffer width. Also the
bottom of the scrolling region is now the bottom of the viewport (rather than
bottom-1), otherwise it would be off by one.
* DL and IL (the `DoSrvPrivateModifyLinesImpl` function)
Again this uses a single rect for both the scroll region and clipping
boundary, and the width is set to `SHORT_MAX` to cover the full width. The
most significant change, though, is that the bottom boundary is now the
viewport bottom rather than the buffer bottom. Using the buffer bottom
prevented it clipping the content that scrolled off screen when inserting,
and failed to fill the revealed area when deleting.
* SU and SD (the `AdaptDispatch::_ScrollMovement` method)
This was already using a single rect for both the scroll region and clipping
boundary, but it was previously constrained to the width of the viewport
rather than the buffer width, so some areas of the screen weren't correctly
scrolled. Also, the bottom boundary was off by 1, because it was using an
exclusive rect while the `ScrollRegion` function expects inclusive rects.
* ICH and DCH (the `AdaptDispatch::_InsertDeleteHelper` method)
This method has been considerably simplified, because it was reimplementing a
lot of functionality that was already provided by the `ScrollRegion`
function. And like many of the other cases, it has been updated to use a
single rect for both the scroll region and clipping boundary, and clip to the
full buffer width rather than the viewport width.
I should add that if we were following the specs exactly, then the SU and SD
commands should technically be panning the viewport over the buffer instead of
moving the buffer contents within the viewport boundary. So SU would be the
equivalent of a newline at the bottom of the viewport (assuming no margins).
And SD would assumedly do the opposite, scrolling the back buffer back into
view (an RI at the top of the viewport should do the same).
This doesn't seem to be something that is consistently implemented, though.
Some terminals do implement SU as a viewport pan, but I haven't seen anyone
implement SD or RI as a pan. If we do want to do something about this, I think
it's best addressed as a separate issue.
## Validation Steps Performed
There were already existing tests for the SU, SD, ICH, and DCH commands, but
they were implemented as adapter tests, which weren't effectively testing
anything - the `ScrollConsoleScreenBufferW` method used in those tests was just
a mock (an incomplete reimplementation of the `ScrollRegion` function), so
confirming that the mock produced the correct result told you nothing about the
validity of the real code.
To address that, I've now reimplemented those adapter tests as screen buffer
tests. For the most part I've tried to duplicate the functionality of the
original tests, but there are significant differences to account for the fact
that scrolling region now covers the full width of the buffer rather than just
the viewport width.
I've also extended those tests with additional coverage for the RI, DL, and IL
commands, which are really just a variation of the SU and SD functionality.
Closes microsoft#21741 parent 2da3b49 commit 12d2e17
4 files changed
Lines changed: 525 additions & 827 deletions
File tree
- src
- host
- ut_host
- terminal/adapter
- ut_adapter
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1356 | 1356 | | |
1357 | 1357 | | |
1358 | 1358 | | |
1359 | | - | |
1360 | | - | |
| 1359 | + | |
| 1360 | + | |
1361 | 1361 | | |
1362 | 1362 | | |
1363 | | - | |
| 1363 | + | |
1364 | 1364 | | |
1365 | | - | |
| 1365 | + | |
1366 | 1366 | | |
1367 | 1367 | | |
1368 | 1368 | | |
1369 | 1369 | | |
1370 | 1370 | | |
1371 | | - | |
1372 | | - | |
1373 | 1371 | | |
1374 | 1372 | | |
1375 | 1373 | | |
1376 | | - | |
| 1374 | + | |
1377 | 1375 | | |
1378 | 1376 | | |
1379 | 1377 | | |
| |||
2033 | 2031 | | |
2034 | 2032 | | |
2035 | 2033 | | |
2036 | | - | |
2037 | | - | |
| 2034 | + | |
| 2035 | + | |
2038 | 2036 | | |
2039 | 2037 | | |
2040 | | - | |
| 2038 | + | |
2041 | 2039 | | |
2042 | | - | |
| 2040 | + | |
2043 | 2041 | | |
2044 | 2042 | | |
2045 | 2043 | | |
| |||
2052 | 2050 | | |
2053 | 2051 | | |
2054 | 2052 | | |
2055 | | - | |
2056 | | - | |
2057 | | - | |
2058 | 2053 | | |
2059 | 2054 | | |
2060 | 2055 | | |
| |||
2068 | 2063 | | |
2069 | 2064 | | |
2070 | 2065 | | |
2071 | | - | |
| 2066 | + | |
2072 | 2067 | | |
2073 | 2068 | | |
2074 | 2069 | | |
| |||
0 commit comments