XAML Islands: Certain mouse events appear to be scaled incorectly on High-DPI displays #2101
Labels
area-Islands
Xaml Islands feature
needs-winui-3
Indicates that feature can only be done in WinUI 3.0 or beyond. (needs winui 3)
team-Reach
Issue for the Reach team
Comments
msft-github-bot
added
the
needs-triage
Austin-Lamb
added
needs-winui-3
|
Thanks for filing this. We won't be able to fix this until WinUI 3. @zadjii-msft - if this is a top issue for Terminal let's discuss more to see if there's anything else we can do but I'm not optimistic. |
This was referenced Mar 24, 2020
ghost
pushed a commit
to microsoft/terminal
that referenced
this issue
Apr 1, 2020
## 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.
donno2048
added a commit
to donno2048/terminal
that referenced
this issue
Sep 28, 2020
## 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.
|
FYI to whoever is on WinUI triage these days: This was promoted internally to MSFT:35026617. It's apparently fixed in Windows 11 (at least from my own experimentation). It also didn't meet the bar for servicing to downlevel Windows 10. Based on that, we can probably close this one out (unless there's significant pushback from the community). |
rozele
added a commit
to rozele/react-native-windows
that referenced
this issue
Jun 29, 2022
It may not always be the case that the XamlRoot is the same size as the HWND. For example, in our app, to work around microsoft/microsoft-ui-xaml#2101, we resize the XamlRoot content to be larger than the window by the DPI scale factor and then resizes the ReactRootView to be the same size as the HWND. However, this breaks the LogBoxModule and the AlertModule, which make the assumption that the XamlRoot is the same size as the window. To workaround this assumption, this change adds an API to XamlUIService that allows you to specify which view under XamlRoot is equivalent to the window size for the purpose of sizing things like the ContentDialog smoke screen and the LogBox popup. Fixes microsoft#10211
rozele
added a commit
to rozele/react-native-windows
that referenced
this issue
Oct 23, 2022
It may not always be the case that the XamlRoot is the same size as the HWND. For example, in our app, to work around microsoft/microsoft-ui-xaml#2101, we resize the XamlRoot content to be larger than the window by the DPI scale factor and then resizes the ReactRootView to be the same size as the HWND. However, this breaks the LogBoxModule and the AlertModule, which make the assumption that the XamlRoot is the same size as the window. To workaround this assumption, this change adds an API to XamlUIService that allows you to specify which view under XamlRoot is equivalent to the window size for the purpose of sizing things like the ContentDialog smoke screen and the LogBox popup. Fixes microsoft#10211
rozele
added a commit
to rozele/react-native-windows
that referenced
this issue
Feb 6, 2023
It may not always be the case that the XamlRoot is the same size as the HWND. For example, in our app, to work around microsoft/microsoft-ui-xaml#2101, we resize the XamlRoot content to be larger than the window by the DPI scale factor and then resizes the ReactRootView to be the same size as the HWND. However, this breaks the LogBoxModule and the AlertModule, which make the assumption that the XamlRoot is the same size as the window. To workaround this assumption, this change adds an API to XamlUIService that allows you to specify which view under XamlRoot is equivalent to the window size for the purpose of sizing things like the ContentDialog smoke screen and the LogBox popup. Fixes microsoft#10211
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
This is being filed to track the following bug in the Windows Terminal: microsoft/terminal#2606
For XAML Islands, it seems that there are a few bugs related to mouse input on high-dpi displays.
Steps to reproduce the bug
(see above issue)
Expected behavior
Version Info
NuGet package version: `Microsoft.UI.Xaml.2.3.191217003-prerelease
I'm seeing this on Microsoft Windows [Version 10.0.19578.1000], RS_ONECORE_DEP, though this has been around for months.
Additional context
I've previously discussed this with @Austin-Lamb and @ocalvo
The text was updated successfully, but these errors were encountered: