[bug] when multiple monitors have different scaling settings, the window cannot switch correctly between monitors

[lh123]

Describe the bug

• monitor 1
  
• monitor 2
  

when multiple monitors have different scaling settings, the window cannot switch correctly between monitors

Reproduction

when multiple monitors have different scaling settings, using windows + shift + Arrow to move a window to another screen, the window does not move correctly to the second screen.

3.mp4

Expected behavior

The window should move correctly to another screen.

Full tauri info output

[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 126.0.2592.87
    ✔ MSVC: Visual Studio ���ɹ��� 2022
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.11.0
    - pnpm: 8.6.3
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 1.7.1
    - tauri-build [RUST]: 1.5.3
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - tauri-cli [RUST]: 1.6.0
    - @tauri-apps/api [NPM]: 1.6.0
    - @tauri-apps/cli [NPM]: 1.6.0

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite

Stack trace

No response

Additional context

No response

[Yoruchiaki]

I have the same problem

[hugoattal]

A similar issue that I have which is probably linked, I find it difficult to move my Tauri app window between screens of different scale.

• By "moving", I mean dragging with the mouse
• By "difficult", I mean that the window keeps getting resized, and I can't make it cross the screen : the window is kind of stuck on the first screen

Here is my setup:

 ----------     ----------     ----------
| Screen 2 |   | Screen 1 |   | Screen 3 |
 ----------     ----------     ----------

• Screen 1 is 2560 x 1440 @ 125%
• Screen 2 and 3 are 1920 x 1080 @ 100%

I found that it's pretty difficult to move my Tauri app windows between Screen 1 and Screen 2, but it's okay between Screen 1 and Screen 3.

Temporal solution I found: move the window slowly between the screens, so it gets resized (due to the change of scale) before the cursor cross the screen.

Note: I'm on Windows 11 using Tauri 2

[ottosson]

I have the exact same issue as @hugoattal. The window moves back while resizing and it's difficult to even get it over to the second monitor. This worked better in Tauri v1. Not perfect but much better than in v2.

Here's my tauri info:

[✔] Environment
    - OS: Windows 10.0.26100 x86_64 (X64)
    ✔ WebView2: 131.0.2903.112
    ✔ MSVC:
        - Visual Studio Build Tools 2019
        - Visual Studio Professional 2022
    ✔ rustc: 1.83.0 (90b35a623 2024-11-26)
    ✔ cargo: 1.83.0 (5ffbef321 2024-10-29)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 22.2.0
    - npm: 10.9.1

[-] Packages
    - tauri :crab:: 2.1.1
    - tauri-build :crab:: 2.0.3
    - wry :crab:: 0.47.2
    - tao :crab:: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-shell :crab:: 2.2.0
    - @tauri-apps/plugin-shell : 2.2.0
    - tauri-plugin-fs :crab:: 2.2.0
    - @tauri-apps/plugin-fs : not installed!
    - tauri-plugin-dialog :crab:: 2.2.0
    - @tauri-apps/plugin-dialog : 2.2.0
    - tauri-plugin-updater :crab:: 2.3.0
    - @tauri-apps/plugin-updater : 2.3.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

[tenglongwentian]

所以还是没有解决？

[dvlpr91]

I'm experiencing the same bug.

I don't think it has ever happened before in the same code as it is now.

I don't know if it's related to the windows11 update.

[its-monotype]

In my case, when moving the window from 100% to 200% scaling, I noticed that issue happens from time to time, and in most cases, when dragging the window quickly or it depends on which part of the window I drag; if you grab it closer to the end of the window opposite to the side where the monitor is located, it seems like the chance of it resizing incorrectly is higher. Does anyone else have the same problem on Windows 11?

[dvlpr91]

In my case, when moving the window from 100% to 200% scaling, I noticed that issue happens from time to time, and in most cases, when dragging the window quickly or it depends on which part of the window I drag; if you grab it closer to the end of the window opposite to the side where the monitor is located, it seems like the chance of it resizing incorrectly is higher. Does anyone else have the same problem on Windows 11?

I am in a Windows 11 environment.

This issue occurs when I move app windows to different monitors with different scales.

This happens whether I move the app window quickly or slowly.

Previously, I solved this by specifying a logical screen size in the WINDOW_SCALE_FACTOR_CHANGED event, but at some point it stopped working correctly, so I removed the logical screen size specification from the event, but found that the default behaviour was already incorrect.

This appears to be a problem with something else it relies on, which is expected to be fixed soon.

rust-windowing/winit#4119

[dgerhardt]

I've opened tauri-apps/tao#1056 to fix this issue by limiting some additional positioning logic to older Windows build versions (Windows 10). This logic is no longer needed and causes issues on Windows 11 (at least on 24H2). But since I'm only running the latest feature release of Windows 11, it would be helpful if some one with an older version (ideally the initial release 21H2) could verify if the issue already occurs there.

This issue's author tested on 10.0.22631, so the problem occurs at least on 23H2 and newer. I would like to know if Windows 11 is effected in general or if the problem started with a specific feature release. If the latter is the case, I would need to adjust the PR accordingly.

[its-monotype]

Actually I remember when it worked fine, and then, if I'm not confusing anything it started after some Windows update probably 24H2