[bug] current_monitor() always returns the external monitor (Ubuntu 22.04)

[matthme]

Describe the bug

Calling current_monitor() on a window just built with the WindowBuilder always returns the external monitor even if the window is clearly opened on the built-in monitor.

Reproduction

I made a repro here on branch wrong-monitor: https://github.com/matthme/menu-stuck-tauri-macos/tree/wrong-monitor

It prints out the monitor of the window.

Expected behavior

Return the monitor where the window is currently residing in.

Platform and versions

Environment
  › OS: Ubuntu 22.04 X64
  › Node.js: 16.11.1
  › npm: 8.0.0
  › pnpm: Not installed!
  › yarn: 1.22.19
  › rustup: 1.25.1
  › rustc: 1.64.0
  › cargo: 1.64.0
  › Rust toolchain: stable-x86_64-unknown-linux-gnu 

Packages
WARNING: no lock files found, defaulting to npm
  › @tauri-apps/cli [NPM]: 1.1.1 (outdated, latest: 1.2.3)
  › @tauri-apps/api [NPM]: Not installed!
  › tauri [RUST]: 1.2.1,
  › tauri-build [RUST]: 1.2.1,
  › tao [RUST]: 0.15.6,
  › wry [RUST]: 0.22.6,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../src
  › devPath: ../src
package.json not found

App directory structure
  ├─ .git
  ├─ src-tauri
  ├─ src
  └─ .vscode

Stack trace

No response

Additional context

No response

[amrbashir]

could you give me the output of:

dbg!(window.current_monitor().unwrap().unwrap().name());
dbg!(window.primary_monitor().unwrap().unwrap().name());
dbg!(window.available_monitors().unwrap().map(|m|m.name()).collect<Vec<_>>());

and also the output of

xrandr --query

[matthme]

Output (after slight modification of your code snippet to make it compile):

[src/main.rs:25] window.current_monitor().unwrap().unwrap().name() = Some(
    "DP-2",
)
[src/main.rs:26] window.primary_monitor().unwrap().unwrap().name() = Some(
    "eDP-1",
)
[src/main.rs:27] window.available_monitors().unwrap().iter().map(|m|
            m.name()).collect::<Vec<_>>() = [
    Some(
        "eDP-1",
    ),
    Some(
        "DP-2",
    ),
]

This output is the same no matter on which monitor I open the window.

Output of xrandr --query:

Screen 0: minimum 320 x 200, current 1920 x 2160, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+0+1080 (normal left inverted right x axis y axis) 309mm x 174mm
   1920x1080     60.00*+  60.00    40.00  
   1680x1050     60.00  
   1400x1050     60.00  
   1600x900      60.00  
   1280x1024     60.00  
   1400x900      60.00  
   1280x960      60.00  
   1440x810      60.00  
   1368x768      60.00  
   1280x800      60.00  
   1280x720      60.00  
   1024x768      60.00  
   960x720       60.00  
   928x696       60.00  
   896x672       60.00  
   1024x576      60.00  
   960x600       60.00  
   960x540       60.00  
   800x600       60.00  
   840x525       60.00  
   864x486       60.00  
   700x525       60.00  
   800x450       60.00  
   640x512       60.00  
   700x450       60.00  
   640x480       60.00  
   720x405       60.00  
   684x384       60.00  
   640x360       60.00  
   512x384       60.00  
   512x288       60.00  
   480x270       60.00  
   400x300       60.00  
   432x243       60.00  
   320x240       60.00  
   360x202       60.00  
   320x180       60.00  
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1920x1080     59.96*+
   1600x1200     60.00  
   1680x1050     74.89    59.95  
   1280x1024     75.02    60.02  
   1440x900      74.98    59.89  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    59.94  
   720x400       70.08  
HDMI-2 disconnected (normal left inverted right x axis y axis)

[amrbashir]

I see what causes the issue now, unfortunately it will take some time to fix. For now, you can workaround this by, creating the window in one command and position it on the desired window, then run the logic that depends on the current monitor in another command.

Also from my testing on KDE, if your main window is on the second monitor, the new window will open on the second monitor and will print the correct monitor. Unfortunately this is not the case on Gnome, no matter what you do, the window seems to be opened on main monitor first, hence the incorrect output of current monitor, then moved to the second monitor. So it is partially Gnome's window manager fault too and even after we fix it on our own, the issue might still exist.

[wusyong]

@amrbashir IIRC we are going to call gtk method directly instead of sending requests to event loop right?
If so, I'll open an issue for this kind of refactoring.

[amrbashir]

yes but unfortunately, it still won't be enough to fix this issue, the same behavior could be seen in winit too. Probably another Gnome bug but if you have the time, please re-test it again just to make sure