[bug] Can't move or resize the main window

[uAtomicBoolean]

Describe the bug

I can't move or resize a window after upgrading to tauri latest rc (2.0.0-rc.3 at that time) when running as dev.
The thing is it doesn't come from that tauri version as downgrading it doesn't solve the problem.

Reproduction

1. Create a minimal tauri app using the latest release candidate.
   cargo create-tauri-app --rc

2. Run the app in dev mode.
   cargo tauri dev

Expected behavior

Be able to move or resize the application's window.

Full tauri info output

WARNING: no lock files found, defaulting to npm

[✔] Environment
    - OS: Fedora 40.0.0 X64
    ✔ webkit2gtk-4.1: 2.44.2
    ✔ rsvg2: 2.57.1
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10)
    ✔ cargo: 1.79.0 (ffa9cf99a 2024-06-03)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 22.6.0
    - npm: 10.8.1
    - bun: 1.1.24

[-] Packages
    - tauri [RUST]: 2.0.0-rc (no lockfile)
    - tauri-build [RUST]: no manifest (no lockfile)
    - wry [RUST]: no manifest (no lockfile)
    - tao [RUST]: no manifest (no lockfile)
    - tauri-cli [RUST]: 2.0.0-rc.3
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-rc.3

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src

Stack trace

No response

Additional context

No response

[loafman-kangjun]

I got the same promble, with the newest RC version. My system information is "Manjaro Arch24 with gnome+wayland".
I've upgrade everything.

[loafman-kangjun]

I found some special things, I install the gtk3 library(pacman -S gtk3 in the "tao" doc),now I can move the window in the "dev" option, but I still can't move the windows in "build" option.

[loafman-kangjun]

This is the difference besides "build"(left, can't move) and "build"(right, can move)

[loafman-kangjun]

I did something more, I found that if I right-click the botton on the titile bar, I can move it.

[uAtomicBoolean]

The issue might come from tauri-runtime-wry. I've found that adding it to the Cargo.toml to set it to its last version (2.0.0-rc.6) brings the bug.

Also, both minimize and close buttons work and I can move the window when "dragging" them.

[✔] Environment
    - OS: Fedora 40 X64
    ✔ webkit2gtk-4.1: 2.44.2
    ✔ rsvg2: 2.57.1
    ✔ rustc: 1.79.0 (129f3b996 2024-06-10)
    ✔ cargo: 1.79.0 (ffa9cf99a 2024-06-03)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 22.6.0
    - npm: 10.8.1
    - bun: 1.1.24

[-] Packages
    - tauri [RUST]: 2.0.0-rc.1
    - tauri-build [RUST]: 2.0.0-rc.1
    - wry [RUST]: 0.42.0
    - tao [RUST]: 0.29.1
    - tauri-cli [RUST]: 2.0.0-rc.3

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:3000/

[loafman-kangjun]

so that we should tell it to the "wry" project. I'm not good at the cases, can you please donging some tests and tell them?

[vlabo]

It also happens in release mode.
For some reason this is specific for Gnome + Wayland

KDE + X11 -> Can resize and move
KDE + Wayland -> Can resize and move
GNOME + X11 -> Can resize and move
GNOME + Wayland -> The issue appears.

[tram98]

Can confirm this bug on Fedora Workstation 40.
rustc 1.80.1 (3f5fd8dd4 2024-08-06)
Kernel: Linux 6.10.6-200.fc40.x86_64
DE: GNOME 46.4
WM: Mutter (Wayland)

[akrpic77]

Same here.

I can move the window if I grab it by minimize/maximize/close button.

Debian sid. Gnome wayland.

[✔] Environment
- OS: Debian n/a x86_64 (X64)
✔ webkit2gtk-4.1: 2.44.3
✔ rsvg2: 2.58.0
✔ rustc: 1.80.1 (3f5fd8dd4 2024-08-06)
✔ cargo: 1.80.1 (376290515 2024-07-16)
✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
- node: 20.11.1
- npm: 9.9.3

[-] Packages
- tauri 🦀: 2.0.0-rc.8
- tauri-build 🦀: 2.0.0-rc.7
- wry 🦀: 0.42.0
- tao 🦀: 0.29.1
- @tauri-apps/api : 2.0.0-rc.4
- @tauri-apps/cli : 2.0.0-rc.8

[-] Plugins
- tauri-plugin-shell 🦀: 2.0.0-rc.3
- @tauri-apps/plugin-shell : 2.0.0-rc.1
- tauri-plugin-updater 🦀: 2.0.0-rc.2
- @tauri-apps/plugin-updater : 2.0.0-rc.1

[-] App
- build-type: bundle
- CSP: unset
- frontendDist: ../dist-tauri
- devUrl: http://localhost:3000/
- framework: Vue.js
- bundler: Rollup

I found out that window example in tao doesn't allow to move/resize window either, but in drag_window example it is possible to move windows (but not resize - it's the example's purpose to show how to make window movable by holding on edges).

[loafman-kangjun]

As you tell. I also found that you can hold down three buttons, such as the minimize button, to move the window.
Something interesting

[amrbashir]

It seems to me that this problem is caused by Ubuntu on Wayland and nothing we can do to fix this on our side since we simply use GTK3 to create the window and it handles resizing on it self.

If there is other GTK3 apps (non-tauri) that exhibits this behavior, then it is probably a bug in Ubuntu on Wayland.

[Khalid-Nowaf]

same issue here on debain 12, when I run
npm run tauri dev

Couldn't get key from code: Unidentified(Gtk(248))
Couldn't get key from code: Unidentified(Gtk(248))

[akrpic77]

using xprop method of detecting if application is running native wayland or thru xwayland (shows crosshair on xwayland and no cursor change on wayland). I have found out:

• Running my app uses native wayland, move/resize DOESN'T work
• Running my app with GDK_BACKEND=wayland uses native wayland, move/resize DOESN'T work
• Running my app with GDK_BACKEND=x11 uses xwayland, move/resize works
• Running gtk's example/application1 with GDK_BACKEND=x11 uses xwayland, move/resize works
• Running gtk's example/application1 with GDK_BACKEND=wayland uses native wayland, move/resize DOES work

This suggests that the problem is in tauri/tao/wry and not in the system.

My current workaround is setting env var "GDK_BACKEND" to x11 at top of the main() function.

p.s. beware of running your app from vs code terminal as it sets GDK_BACKEND to x11

[amrbashir]

Thanks @akrpic77 for the investigation, I will see if I we are doing something finky in our code once I get my linux machine setup.

I still don't understand why would KDE+Wayland work but not Gnome+Wayland.

[Khalid-Nowaf]

I have built a release .deb and .AppImage.

the .AppImage works fine with resizing and moving, since it shipped with all dependencies and does not use any system libs.

[FabianLars]

The appimage also forces GDK_BACKEND=x11 though.

[ndom91]

I've gone through and tried all tauri-runtime-wry versions from rc.8 back down to rc.2 and it seems that it really has broken in rc.3, that was the first release where my app also began experiencing these issues in wayland+gnome DE's

[akrpic77]

following on hint by @ndom91, I found out that reversing changes of fix(linux): prevent firing duplicate mouse events in tao fixes move/size issue, but brings back duplicate mouse events.

[Khalid-Nowaf]

following on hint by @ndom91, I found out that reversing changes of fix(linux): prevent firing duplicate mouse events in tao fixes move/size issue, but brings back duplicate mouse events.

I think this is relevant, because I managed to move the window one time by holding the click for some time. But I did not know how to produce it again.

[goenning]

based on all the comments above, this is the hacky fix I have, which seems to work.

If you have a better solution, please share :)

if env::var("APPIMAGE").is_ok() || std::env::var("FLATPAK_ID").is_ok() {
    return;
}

let desktop = env::var("XDG_CURRENT_DESKTOP").unwrap_or_default().to_lowercase();
if desktop.contains("gnome") {
    env::set_var("GDK_BACKEND", "x11");
}

[ndom91]

Tauri 2 includes the ability to pass a .desktop file template for deb and rpm. So we decided to do something similar ^^ and prefix env GDK_BACKEND=x11 before the preexisting Exec= key contents

[fogzot]

Using the X11 backend is not a solution, it is a hack. I hope this can be fixed in TAO.

[ndom91]

Using the X11 backend is not a solution, it is a hack. I hope this can be fixed in TAO.

Right, but it's a workaround for now for folks that made the migration to Tauri v2 already and don't want to go back

[Khalid-Nowaf]

This issue is blocking me from releasing my app (the app is not usable). Are we expecting a fix in the upcoming releases?

[Zamoca42]

@Khalid-Nowaf I have implemented a header for Wayland, and it will be included in the next version once tauri-apps/tao#982 is released.

[amrbashir]

Closed by tauri-apps/tao#979, if the issue happens after release, please let me know

[ninjadev64]

I'm still getting this in my app OpenDeck after updating to the stable release.

Edit: it's the same behaviour, I'm on GNOME + Wayland, and I can move the window by dragging the decoration buttons, and can't resize.

[amrbashir]

@ninjadev64 apologies, we forgot to release the tao dependency, I have released it now, run cargo update -p tao in src-tauri and see if the issue is fixed.

[fogzot]

@amrbashir i tested the new release and that's not really a solution. The custom header has 2 serious problems:

1. the header does not follow the platform theme (light/dark);
2. the size of the window is wrong because the header height is not taken into account. This means that the available area is different between platforms with Linux Wayland getting less vertical space than, for example, Windows.

Please, reopen this bug report until a proper fix is implemented.

[Zamoca42]

2. the size of the window is wrong because the header height is not taken into account. This means that the available area is different between platforms with Linux Wayland getting less vertical space than, for example, Windows.

In my opinion, this is a separate issue. There was already a problem with the window not being created accurately even before the custom header.

see: tauri-apps/tao#929

[fogzot]

@Zamoca42 I didn't note that when using the RC versions that still had the bug (and the native headerbar?). Anyway the current situation under Linux/Wayland is terrible.

[ninjadev64]

@ninjadev64 apologies, we forgot to release the tao dependency, I have released it now, run cargo update -p tao in src-tauri and see if the issue is fixed.

Seems to be fixed, thanks.