search

tauri-apps / tauri

Build smaller, faster, and more secure desktop applications with a web frontend.
https://tauri.app
Apache License 2.0
81.77k stars 2.45k forks source link

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

Open uAtomicBoolean opened 3 weeks ago

uAtomicBoolean commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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

loafman-kangjun commented 3 weeks ago

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

uAtomicBoolean commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 1 week ago

Same here.

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

Debian sid. Gnome wayland.

[✔] Environment

[-] Packages

[-] Plugins

[-] App

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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:

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

The appimage also forces GDK_BACKEND=x11 though.

ndom91 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 4 days ago

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 commented 3 days ago

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 commented 2 days ago

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

ndom91 commented 2 days ago

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