-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Dragging a tab makes the window slowly scroll up for a while even after not dragging the tab anymore #9109
Comments
Well that certainly looks insane. I can't get this to repro at all though, unfortunately. Who knows, maybe this will be made better with #1256, or far far worse. I guess we'll leave this open on the backlog for now. |
This looks like it has something to do with the auto-scroll behavior when dragging and dropping: when an object is being dragged by the cursor and the cursor is near an edge of a scrollable container, the container will think the user is wanting to scroll to reveal the portion of the container that the user wants to drop the object to. And Windows terminal's console container is also doing that except that it doesn't stop when the mouse has been released. |
Is there some sort of Windows setting that controls that? Because we certainly didn't implement anything like that for the Terminal 😄 We do support "dragging a selection outside the control will scroll the control", but nothing for "dragged something over the edge of the control will scroll the control". Holy crap I got it to repro. I figured out what's different between mine & OP's setup - you need to drag the tab into the padding. If you're in the padding, then we'll try and start an autoscroll, even without a selection. This'll be a trivial fix once #9820 lands |
This is kind of annoying that the auto-scrolling is handled by the TermControl, but it uses a timer that's still a WinUI construct. We only want to start the auto-scrolling behavior when the drag started _inside_ the control. Otherwise, in the tab drag scenario, dragging into the bounds of the TermControl will trick it into thinking it should start a scroll.
## Summary of the Pull Request This fixes two bugs related to dragging into the bounds of the `TermControl`. Although the fixes are fairly small, I'm batching them up, because I don't want to stack 2 more PRs on top of #10051. * #9109 - This is fixed by only starting an autoscroll if the click&drag actually started within the bounds of the control. * #4603 - Building on the above change, only modify the selection when the drag started in the control. ## References * srsly go read #10051. ## PR Checklist * [x] Closes #9109 * [x] Closes #4603 * [x] I work here * [x] Test added * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This is kind of annoying that the auto-scrolling is handled by the TermControl, but it uses a timer that's still a WinUI construct. We only want to start the auto-scrolling behavior when the drag started _inside_ the control. Otherwise, in the tab drag scenario, dragging into the bounds of the TermControl will trick it into thinking it should start a scroll.
🎉This issue was addressed in #10650, which has now been successfully released as Handy links: |
Environment
Steps to reproduce
Expected behavior
It shouldn't scroll up forever when you do that
Actual behavior
If the terminal can scroll up it will scroll up slowly and go on until you click in the terminal
video: https://www.youtube.com/watch?v=o0T1jeFemvQ
The text was updated successfully, but these errors were encountered: