Fix mouse coordinates when viewport is scrolled for all events, not just pressed #11290
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zadjii-msft
approved these changes
Sep 22, 2021
34 tasks
DHowett
approved these changes
Sep 22, 2021
|
@msftbot merge this in 1 minute |
|
Hello @DHowett! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
|
🎉 Handy links: |
|
🎉 Handy links: |
|
🎉 Handy links: |
DHowett
added a commit
that referenced
this pull request
Aug 23, 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 pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Does the mouse coordinate adjustment added in #10642 for all the other mouse events as well (moved, released, wheel)
Closes #10190