-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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.
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
Fix mouse coordinates when viewport is scrolled #10642
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
blocking for discussion about what happens to out of bounds coords
I'm fine with out of bounds coordinates blackholing since it was said that it matches the known behavior of other terminals. |
Yep, thats what this PR does |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hate to be a pill... but since we can now write tests for ControlInteractivity, is there a way you can write a test for this? 😄
@@ -182,7 +182,12 @@ namespace winrt::Microsoft::Terminal::Control::implementation | |||
} | |||
else if (_canSendVTMouseInput(modifiers)) | |||
{ | |||
_core->SendMouseEvent(terminalPosition, pointerUpdateKind, modifiers, 0, buttonState); | |||
const auto adjustment = _core->ScrollOffset() > 0 ? _core->BufferHeight() - _core->ScrollOffset() - _core->ViewHeight() : 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised we don't already have a thing that calculates "how far back from the top line are we scrolled"... hmm.
Test added! |
…/pabhoj/mouse_viewport_fix
…crosoft/terminal into dev/pabhoj/mouse_viewport_fix
true, // focused, | ||
cursorPosition1); | ||
Log::Comment(L"Verify that there's still no selection"); | ||
VERIFY_IS_FALSE(core->HasSelection()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we may not have a way to test that it actually doesn't generate mouse events. oh well 😄
@zadjii-msft any ideas? would we need the mock connection to tell us? that sounds tedious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ew yea that would probably require a lot more plumbing than it's worth.
Hello @zadjii-msft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
## Summary of the Pull Request Adjust the y-coordinate of the mouse coordinates we send based on how much the viewport has been scrolled ## Validation Steps Performed Validated: cannot repro the issue in microsoft#10190 Closes microsoft#10190
🎉 Handy links: |
🎉 Handy links: |
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
Summary of the Pull Request
Adjust the y-coordinate of the mouse coordinates we send based on how much the viewport has been scrolled
Validation Steps Performed
Validated: cannot repro the issue in #10190
Closes #10190