[bug] broken IPC in multi window app on Linux
Ynng opened this issue · 9 comments
Describe the bug
In a multi-window Tauri app on Linux, only the first window ever created can receive events and have its listen
callbacks triggered. All subsequent windows do not receive any events.
In this video, the same Tauri app runs on Windows on the left and Linux on the right.
Every window ran listen("reply", (event) => {alert(event.payload})})
.
When the button is pressed, a Rust Tauri command is invoked, which emits the reply
event.
On Windows, the app behaves correctly and every window receives the reply
event.
On Linux, only the first window ever receives any events.
Screencast.from.2024-09-27.23-42-14.mp4
Reproduction
The example shown in the video: https://github.com/Ynng/tauri-listen-test
Or:
- Clone the tauri repo on an Ubuntu 24 machine
- Run
cargo run --example multiwindow
- Try to send a message to the second/third window
Expected behavior
All windows should receive events that are "emitted to all targets".
Full tauri info
output
[✔] Environment
- OS: Fedora 40.0.0 x86_64 (X64)
✔ webkit2gtk-4.1: 2.44.3
✔ rsvg2: 2.57.1
✔ 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 (environment override by RUSTUP_TOOLCHAIN)
- node: 21.7.2
- pnpm: 9.7.1
- npm: 10.5.0
[-] Packages
- tauri 🦀: 2.0.0-rc.11
- tauri-build 🦀: 2.0.0-rc.13
- wry 🦀: 0.44.1
- tao 🦀: 0.30.2
- tauri-cli 🦀: 2.0.0-rc.10
[-] Plugins
- tauri-plugin-shell 🦀: 2.0.0-rc.0
[-] App
- build-type: bundle
- CSP: unset
- frontendDist: ../dist
- devUrl: http://localhost:1420/
Stack trace
No response
Additional context
It appears that this bug was introduced in tauri version 2.0.0-rc.16
.
I tested with tauri
pinned to version =2.0.0-rc.15
and tauri-utils
pinned to version =2.0.0-rc.12
, and the bug does not occur
The problem still exists on Tauri 2.0.0 stable
I just ran into this today too.
One other thing I noticed is that the injected window in the #[command]
is always the main window, too.
For example, this prints main
on Linux, when it prints settings
on macOS
#[tauri::command]
async fn cmd_update_settings(settings: Settings, w: WebviewWindow) -> Result<Settings, String> {
println!("UPDATE SETTINGS {}", w.label());
update_settings(&w, settings)
.await
.map_err(|e| e.to_string())
}
Perhaps the same root cause, but it seems like data-tauri-drag-region="true"
is also broken in additional windows on Linux
I just ran into this today too.
One other thing I noticed is that the injected window in the
#[command]
is always the main window, too.For example, this prints
main
on Linux, when it printssettings
on macOS#[tauri::command] async fn cmd_update_settings(settings: Settings, w: WebviewWindow) -> Result<Settings, String> { println!("UPDATE SETTINGS {}", w.label()); update_settings(&w, settings) .await .map_err(|e| e.to_string()) }
I'm fairly certain this is the cause of the "event listening issue" I described.
The listen
command is getting the wrong webview object.
I think I figured out the problem:
tauri/crates/tauri-runtime-wry/src/lib.rs
Lines 4136 to 4162 in 193dc4e
As documented, on Linux, custom protocols are associated with the web context and thus we can't register a scheme more than once.
However, every webview want its own tauri
, ipc
and asset
handlers.
On Linux, only the first window's handlers are registered.
Secondary windows' handlers are simply ignored.