prevent incorrect shifting of window when dragging onto monitor with different DPI #4119
Conversation
|
I ran into the same issue during development of a Tauri/TAO app and also came to the conclusion that the custom positioning is not only unnecessary, but breaks on Windows 11. There is a difference in behavior between Windows 10 and 11. On Windows 11 (without the custom positioning), the Window remains at the same relative position to the cursor when moving between monitors. This is not the case on Windows 10 and this is what I think the custom positioning logic attempts to fix. I've created a similar fix for TAO but kept the logic conditionally for Windows 10 (build < 22000) just to be safe. But I'm not sure if it is worth to keep that much logic just for minimal positioning optimizations, especially now that Windows 10 will soon reach EOL. Related PR and issues (TAO seems still uses the same logic since it was forked from winit, so I think they are relevant):
|
changelogmodule if knowledge of this change could be valuable to usersUpdated documentation to reflect any user-facing changes, including notes of platform-specific behaviorCreated or updated an example program if it would help users understand this functionalityThis PR fixes this issue: #4041
The code I deleted has a validation to check if the new window bounds which Windows is suggesting to move the monitor to is actually on the monitor which triggered the
WM_DPI_CHANGEDevent. If that validation fails, it tried to move the window such that it will be on the monitor which triggered theWM_DPI_CHANGEDevent. However, this validation was buggy and was actually causing this bug. It was moving the window off of the intended monitor. It seems this is no longer necessary. For example, Chromium's DPI changed handler does not contain an analogous check.Before
https://www.loom.com/share/aefc5dc1027a42fc8f462c23621ce9a5
After
https://www.loom.com/share/81351dcb5938463c8bb60a66b2a0641b