ScrollConsoleScreenBuffer API shouldn't be affected by DECSTBM margins

[j4james]

Environment

Windows build number: Version 10.0.18362.239

Steps to reproduce

Compile and run the following C++ code:

#include <windows.h>
#include <conio.h>
#include <stdio.h>

int main()
{
  HANDLE handle = GetStdHandle(STD_OUTPUT_HANDLE);

  // Enable support for VT esape sequences
  DWORD mode;
  GetConsoleMode(handle, &mode);
  mode |= ENABLE_VIRTUAL_TERMINAL_PROCESSING;
  SetConsoleMode(handle, mode);

  // Set the viewport and buffer size to 40 x 15
  SHORT width = 40;
  SHORT height = 15;
  SMALL_RECT viewRect = { 0, 0, width - 1, height - 1 };
  SetConsoleWindowInfo(handle, true, &viewRect);
  SetConsoleScreenBufferSize(handle, { width, height });
  SetConsoleWindowInfo(handle, true, &viewRect);

  // Write some content into the viewport
  for (SHORT y = 0; y < height; y++) {
    SetConsoleCursorPosition(handle, { 0, y });
    for (SHORT x = 0; x < width; x++)
      printf("%c", y+65);
  }

  // Set the DECSTBM margins to lines 6 to 10
  printf("\033[6;10r");

  // Set the scroll rectangle to the maximum size
  SMALL_RECT scrollRect = { 0, 0, 32767, 32767 };

  // Set the destination position 4 lines down
  COORD destPos{0, 4};

  // Set the clip rectangle to an area in the center
  SMALL_RECT clipRect = { 2, 2, 37, 12 };

  // Set the fill attributes
  CHAR_INFO fill;
  fill.Char.UnicodeChar = L' ';
  fill.Attributes = 0x4F;

  // Move the specified content down by 4 lines
  ScrollConsoleScreenBuffer(handle, &scrollRect, &clipRect, destPos, &fill);

  // Reset the DECSTBM margins
  printf("\033[r");

  // Wait for a keypress
  _getch();

  return 0;
}

Expected behavior

I'd expect the ScrollConsoleScreenBuffer to behave exactly as specified in the documentation. So the viewport content should be moved down by 4 lines, but only altering the area within the clipRect. I wouldn't expect the DECSTBM margins to have any affect on this operation.

Essentially the output should look like this:

Actual behavior

The vertical extent of the affected area seems to be determined by the DECSTBM margins rather than the clipRect, and the viewport content is actually moved up by 1 line instead of down by 4.

I could possibly imagine it was intentional for the DECSTBM margins to have an affect if it wasn't for the fact that the scroll direction was backwards. So I'm almost certain that this is not the intended behaviour.

As I mentioned in issue #2543, I think this is another argument in favor of removing the DECSTBM margin checking from the ScrollRegion function.