Restore off-the-top behavior for VT mouse mode #17779
Merged
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
This will need to be undone when we move timers and autoscroll down.
microsoft-github-policy-service
bot
added
Issue-Bug
zadjii-msft
approved these changes
Aug 22, 2024
lhecker
approved these changes
Aug 22, 2024
| @@ -334,14 +334,17 @@ namespace winrt::Microsoft::Terminal::Control::implementation | |||
| const ::Microsoft::Terminal::Core::ControlKeyStates modifiers, | |||
| const bool focused, | |||
| const Core::Point pixelPosition, | |||
| const bool pointerPressedInBounds) | |||
| const bool pointerPressedInBounds, | |||
| bool& suppressFurtherHandling) | |||
There was a problem hiding this comment.
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.
lhecker
approved these changes
Aug 23, 2024
PankajBhojwani
approved these changes
Aug 23, 2024
lhecker
approved these changes
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. |
|
Specifically, drags that start in the viewport and move outside it. |
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
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.
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
ScrollOffsetwas greater than 0. It turns out thatScrollOffsetis 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
ControlInteractivityto halt further event processing. It's crude.Refs #10190
Closes #17744