Skip to content
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

Merged
11 commits merged into from
Jul 20, 2021
Merged

Conversation

PankajBhojwani
Copy link
Contributor

@PankajBhojwani PankajBhojwani commented Jul 12, 2021

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

@ghost ghost added Area-Input Related to input processing (key presses, mouse, etc.) Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal. labels Jul 12, 2021
Copy link
Member

@DHowett DHowett left a 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

@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jul 13, 2021
@miniksa
Copy link
Member

miniksa commented Jul 15, 2021

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.

@PankajBhojwani
Copy link
Contributor Author

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

Copy link
Member

@DHowett DHowett left a 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? 😄

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 16, 2021
@@ -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;
Copy link
Member

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.

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 16, 2021
@PankajBhojwani
Copy link
Contributor Author

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? 😄

Test added!

true, // focused,
cursorPosition1);
Log::Comment(L"Verify that there's still no selection");
VERIFY_IS_FALSE(core->HasSelection());
Copy link
Member

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.

Copy link
Member

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.

@zadjii-msft zadjii-msft added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jul 20, 2021
@ghost
Copy link

ghost commented Jul 20, 2021

Hello @zadjii-msft!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

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 (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 6ce2543 into main Jul 20, 2021
@ghost ghost deleted the dev/pabhoj/mouse_viewport_fix branch July 20, 2021 21:39
Rosefield pushed a commit to Rosefield/terminal that referenced this pull request Jul 22, 2021
## 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
DHowett pushed a commit that referenced this pull request Aug 25, 2021
Adjust the y-coordinate of the mouse coordinates we send based on how much the viewport has been scrolled

Validated: cannot repro the issue in #10190

Closes #10190
@ghost
Copy link

ghost commented Aug 31, 2021

🎉Windows Terminal Preview v1.10.2383.0 has been released which incorporates this pull request.:tada:

Handy links:

@ghost
Copy link

ghost commented Aug 31, 2021

🎉Windows Terminal Preview v1.11.2421.0 has been released which incorporates this pull request.:tada:

Handy links:

ghost pushed a commit that referenced this pull request Sep 22, 2021
…ust pressed (#11290)

Does the mouse coordinate adjustment added in #10642 for all the other mouse events as well (moved, released, wheel)

Closes #10190
miniksa pushed a commit that referenced this pull request Sep 27, 2021
…ust pressed (#11290)

Does the mouse coordinate adjustment added in #10642 for all the other mouse events as well (moved, released, wheel)

Closes #10190
miniksa pushed a commit that referenced this pull request Sep 27, 2021
…ust pressed (#11290)

Does the mouse coordinate adjustment added in #10642 for all the other mouse events as well (moved, released, wheel)

Closes #10190
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
Labels
Area-Input Related to input processing (key presses, mouse, etc.) AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-2 A description (P2) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Win32 mouse coordinates wrong when viewport scrolled
6 participants