-
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
Can't scroll or drag files over some areas with non 100% scaling #2606
Comments
@Austin-Lamb & @ocalvo might be interested in this |
I just want to say we all really appreciate how robust this bug report is and how well you've investigated it. |
Oh no, this is likely a platform bug. We've got a discussion with some folks on the XAML team to help investigate this, but I think this isn't going to make the 1.0 cut. This issue is now tracking the internal bugs MSFT:25518888 and MSFT:23625486, and the external microsoft/microsoft-ui-xaml#2101 |
## Summary of the Pull Request As we've learned in #979, not all touchpads are created equal. Some of them have bad drivers that makes scrolling inactive windows not work. For whatever reason, these devices think the Terminal is all one giant inactive window, so we don't get the mouse wheel events through the XAML stack. We do however get the event as a `WM_MOUSEWHEEL` on those devices (a message we don't get on devices with normally functioning trackpads). This PR attempts to take that `WM_MOUSEWHEEL` and manually dispatch it to the `TermControl`, so we can at least scroll the terminal content. Unfortunately, this solution is not very general purpose. This only works to scroll controls that manually implement our own `IMouseWheelListener` interface. As we add more controls, we'll need to continue manually implementing this interface, until the underlying XAML Islands bug is fixed. **I don't love this**. I'd rather have a better solution, but it seems that we can't synthesize a more general-purpose `PointerWheeled` event that could get routed through the XAML tree as normal. ## References * #2606 and microsoft/microsoft-ui-xaml#2101 - these bugs are also tracking a similar "inactive windows" / "scaled mouse events" issue in XAML ## PR Checklist * [x] Closes #979 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments I've also added a `til::point` conversion _to_ `winrt::Windows::Foundation::Point`, and some scaling operators for `point` ## Validation Steps Performed * It works on my HP Spectre 2017 with a synaptics trackpad - I also made sure to test that `tmux` works in panes on this laptop * It works on my slaptop, and DOESN'T follow this hack codepath on this machine.
Also adding MSFT:35026617 to the list of internal tracking issues, since 23625486 was resolved, but didn't fix this. |
Alrighty so MSFT:35026617 was fixed earlier this year, but unfortunately doesn't make the cut to service back to Windows 10. Alas 🤷. Anyways, this is fixed on the latest Windows 11 builds, so I'm gonna close this out, since there's nothing else for us to do here. Thanks! |
Still not working. Recording.2023-11-17.094703.mp4 |
Environment
Steps to reproduce
scroll inactive window when I hover over them
Expected behavior
Terminal should scroll
Actual behavior
Scrolling behavior is different depending on the mouse position. In some areas, it scrolls properly. In other regions, scrolling won't work.
Heres what I think is happening:
With
scroll inactive window
off, the wm_mousewheel messages are only be sent to current focused window (If i've read the docs correctly).I think that the window that takes focus is not scaled properly so in some areas the mouse is 'outside' and won't receive the mouse wheel messages (maybe it needs to be focused and hovered?).
Terminal does have a couple windows (the host and the xaml island ones) but i'm not sure which one takes focus when terminal is active. I tried checking for wm_mousewheel in the window procs but I could not see the message being sent.
I have my suspicions that it's the top level window that is supposed to be receiving the messages because using Spy++, when I highlighted the top level window, its size also matched the area where scrolling works. But visually, everything seems to be scaled properly so I'm not too sure now.
The text was updated successfully, but these errors were encountered: