Fix #19390: Make snap-on-input conditional to prevent blocking programmatic scroll #19414

vididvidid · 2025-10-06T13:41:13Z

Summary of the Pull Request

This PR fixes a bug where programmatic scrolling would get stuck. The fix makes the "snap-on-input" feature conditional, activating it only for modern applications that use Virtual Terminal (VT) processing. This restores correct scrolling behavior for legacy applications without removing the feature for new ones.

References and Relevant Issues

Fixes #19390: OpenConsole: Cursor visibility prevents programmatic scrolling

Detailed Description of the Pull Request / Additional comments

The "snap-on-input" feature introduced in a previous PR caused an unintended side effect for older console programs that use the SetConsoleWindowInfo API to manage their own viewport. When such a program tried to scroll using a key press, the snap feature would immediately pull the view back to the cursor's position, causing the screen to flicker and get stuck.

This fix makes the snap-on-input feature smarter by checking the application's mode first.

Validation Steps Performed

Compiled the minimal C++ reproduction case from issue #19390.

Ran the test executable inside the newly built OpenConsole.exe.

Confirmed that scrolling with the Up/Down arrow keys now works correctly, even with a visible cursor. The view no longer flickers or gets stuck when the cursor moves outside the viewport.

Closes #19390

vididvidid · 2025-10-06T13:49:50Z

@microsoft-github-policy-service agree

lhecker

I'm OOTL but this makes sense to me. 👍

lhecker · 2025-10-06T17:35:06Z

src/host/screenInfo.hpp

    void SetCursorType(const CursorType Type, const bool setMain = false) noexcept;

+    void SetSnapOnInputEnabled(const bool enabled) noexcept { _snapOnInputEnabled = enabled; }
+    [[nodiscard]] bool IsSnapOnInputEnabled() const noexcept { return _snapOnInputEnabled; }


For consistency I think these should go into the .cpp file (they aren't templates).

lhecker · 2025-10-06T17:35:15Z

src/host/screenInfo.cpp


 void SCREEN_INFORMATION::MakeCursorVisible(til::point position)
 {
+


lhecker · 2025-10-06T17:35:23Z

src/host/input.cpp

        }
    }
+
+


DHowett · 2025-10-06T17:53:47Z

@lhecker qq about your thought process here - do you have a gut feeling about introducing new (possibly torn) state boolean rather than just the input mode directly?

DHowett

(want to noodle about this a little bit, sorry!)

lhecker · 2025-10-06T17:59:31Z

Oh right I didn't think of that, since the input mode is stored elsewhere. Regarding duplicating it: my thought was that if we were to add a user setting for this (hypothetically), I would make it a bitfield, similar to the new "cursor inhibitors".

For now, I suppose it makes sense to just ask the input mode.

vididvidid · 2025-10-06T21:20:51Z

I think I just chose the long way to do it. There can be another way, like this:

Just change the file input.cpp and add the following line in the HandleGenericKeyEvent Function :

if (WI_IsFlagSet(buffer.OutputMode, ENABLE_VIRTUAL_TERMINAL_PROCESSING))
{
    buffer.SnapOnInput(keyEvent.wVirtualKeyCode);
}

vididvidid · 2025-10-06T21:23:05Z

Do you want me to remove all of that and prefer this change...

carlos-zamora · 2025-11-04T20:03:42Z

Bump @DHowett and @lhecker for feedback

lhecker · 2025-11-04T20:09:06Z

Just change the file input.cpp and add the following line in the HandleGenericKeyEvent Function : [...]

Yes, that's what Dustin meant with his comment. I think we should do that.

vididvidid · 2025-11-08T09:15:23Z

@DHowett and @lhecker I've updated the pull request. I've reverted the old changes (like _snapOnInputEnabled) and applied the simpler fix to check buffer.OutputMode directly in HandleGenericKeyEvent, as we discussed.

This should be ready for another review. Thanks!

carlos-zamora · 2025-11-19T18:28:54Z

/azp run

azure-pipelines · 2025-11-19T18:29:05Z

Azure Pipelines successfully started running 1 pipeline(s).

carlos-zamora · 2025-11-19T18:32:39Z

(extracted from PR body)
Here is a video demonstrating the fix:

MicrosoftScreenFix.mp4

carlos-zamora

Nice and simple. Thanks! 🙂 Sorry for the delays!

Looks like the original concern was regarding a possible torn state (see #19414 (comment))

New implementation removed that issue

…mmatic scroll (#19414) ## Summary of the Pull Request This PR fixes a bug where programmatic scrolling would get stuck. The fix makes the "snap-on-input" feature conditional, activating it only for modern applications that use Virtual Terminal (VT) processing. This restores correct scrolling behavior for legacy applications without removing the feature for new ones. ## References and Relevant Issues Fixes #19390: OpenConsole: Cursor visibility prevents programmatic scrolling ## Detailed Description of the Pull Request / Additional comments The "snap-on-input" feature introduced in a previous PR caused an unintended side effect for older console programs that use the SetConsoleWindowInfo API to manage their own viewport. When such a program tried to scroll using a key press, the snap feature would immediately pull the view back to the cursor's position, causing the screen to flicker and get stuck. This fix makes the snap-on-input feature smarter by checking the application's mode first. ## Validation Steps Performed Compiled the minimal C++ reproduction case from issue #19390. Ran the test executable inside the newly built OpenConsole.exe. Confirmed that scrolling with the Up/Down arrow keys now works correctly, even with a visible cursor. The view no longer flickers or gets stuck when the cursor moves outside the viewport. Closes #19390 (cherry picked from commit c28610d) Service-Card-Id: PVTI_lADOAF3p4s4BBcTlzgfZNLg Service-Version: 1.24

lhecker approved these changes Oct 6, 2025

View reviewed changes

DHowett previously requested changes Oct 6, 2025

View reviewed changes

microsoft-github-policy-service bot added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Oct 6, 2025

microsoft-github-policy-service bot removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Oct 6, 2025

vididvidid requested review from DHowett and lhecker October 6, 2025 21:32

removed the previous changes added the changes to the input.cpp

0485501

vididvidid force-pushed the fix-scrolling-bug branch from beef806 to 0485501 Compare November 8, 2025 09:11

lhecker approved these changes Nov 18, 2025

View reviewed changes

lhecker added this to the Terminal v1.25 milestone Nov 18, 2025

carlos-zamora approved these changes Nov 19, 2025

View reviewed changes

carlos-zamora enabled auto-merge (squash) November 19, 2025 18:34

carlos-zamora merged commit c28610d into microsoft:main Nov 19, 2025
13 of 15 checks passed


		void SCREEN_INFORMATION::MakeCursorVisible(til::point position)
		{

Fix #19390: Make snap-on-input conditional to prevent blocking programmatic scroll #19414

Fix #19390: Make snap-on-input conditional to prevent blocking programmatic scroll #19414

Uh oh!

Conversation

vididvidid commented Oct 6, 2025 • edited by carlos-zamora Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of the Pull Request

References and Relevant Issues

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

Uh oh!

vididvidid commented Oct 6, 2025

Uh oh!

lhecker left a comment

Choose a reason for hiding this comment

Uh oh!

lhecker Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

lhecker Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

lhecker Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

DHowett commented Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DHowett left a comment

Choose a reason for hiding this comment

Uh oh!

lhecker commented Oct 6, 2025

Uh oh!

vididvidid commented Oct 6, 2025

Uh oh!

vididvidid commented Oct 6, 2025

Uh oh!

carlos-zamora commented Nov 4, 2025

Uh oh!

lhecker commented Nov 4, 2025

Uh oh!

vididvidid commented Nov 8, 2025

Uh oh!

carlos-zamora commented Nov 19, 2025

Uh oh!

azure-pipelines bot commented Nov 19, 2025

Uh oh!

carlos-zamora commented Nov 19, 2025

Uh oh!

carlos-zamora left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

vididvidid commented Oct 6, 2025 •

edited by carlos-zamora

Loading

DHowett commented Oct 6, 2025 •

edited

Loading