Skip to content

Conversation

@DHowett
Copy link
Member

@DHowett DHowett commented Aug 22, 2024

PR #10642 and #11290 introduced an adjustment for the cursor position used to generate VT mouse mode events.

One of the decisions made in those PRs was to only send coordinates where Y was >= 0, so if you were off the top of the screen you wouldn't get any events. However, terminal emulators are expected to send clamped events when the mouse is off the screen. This decision broke clamping Y to 0 when the mouse was above the screen.

The other decision was to only adjust the Y coordinate if the core's ScrollOffset was greater than 0. It turns out that ScrollOffset is 0 when you are scrolled all the way back in teh buffer. With this check, we would clamp coordinates properly until the top line of the scrollback was visible, at which point we would send those coordinates over directly. This resulted in the same weird behavior as observed in #10190.

I've fixed both of those things. Core is expected to receive negative coordinates and clamp them to the viewport. ScrollOffset should never be below 0, as it refers to the top visible buffer line.

In addition to that, #17744 uncovered that we were allowing autoscrolling to happen even when VT mouse events were being generated. I added a way for ControlInteractivity to halt further event processing. It's crude.

Refs #10190
Closes #17744

This will need to be undone when we move timers and autoscroll down.
@microsoft-github-policy-service microsoft-github-policy-service bot added Issue-Bug It either shouldn't be doing this or needs an investigation. Area-Input Related to input processing (key presses, mouse, etc.) Product-Terminal The new Windows Terminal. labels Aug 22, 2024
@DHowett DHowett requested a review from PankajBhojwani August 22, 2024 21:22
const Core::Point pixelPosition,
const bool pointerPressedInBounds)
const bool pointerPressedInBounds,
bool& suppressFurtherHandling)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we change this to a return value it'd probably be worth adding a comment that "return true" means "suppress further handlings" just in case this helps someone in the future.

@DHowett DHowett enabled auto-merge (squash) August 23, 2024 01:25
@DHowett
Copy link
Member Author

DHowett commented Aug 23, 2024

Honestly the 100% correct behavior is to accept drag and move events off the top of the buffer but not click or button events.

@DHowett
Copy link
Member Author

DHowett commented Aug 23, 2024

Specifically, drags that start in the viewport and move outside it.

@DHowett DHowett merged commit d1a1f98 into main Aug 23, 2024
@DHowett DHowett deleted the dev/duhowett/fix-mouse-coords-once-and-for-all branch August 23, 2024 16:43
@BDisp
Copy link

BDisp commented Aug 23, 2024

Honestly the 100% correct behavior is to accept drag and move events off the top of the buffer but not click or button events.

The main reason to caught mouse events above the top is for example to get button released event to take some action. I hope the mouse button events are available. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Product-Terminal The new Windows Terminal.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Mouse events are not sent when the mouse is outside the top of the WT

6 participants