fix(linux): resolve startup hang caused by Webview log target deadlock#150
Conversation
On Linux/Windows, tauri_plugin_log's Webview target deadlocks on the first log::info! call inside setup(). The WebKitGTK IPC socket is registered with mio (token=Token(1), interests=READABLE) before the webview process exists, so the epoll event never fires and setup() blocks forever - the app window never appears. Fix by restricting the Webview log target to macOS only via #[cfg(target_os = "macos")], where initialisation order is safe. Stdout and LogDir targets are unaffected on all platforms. Also fix Cargo.toml: macos-private-api cannot be in the base [dependencies] on Linux because tauri-build validates that the feature matches "macOSPrivateApi": true in the merged tauri.conf.json. That key only exists in tauri.macos.conf.json, which is merged at build time on macOS only. Move macos-private-api to [target.'cfg(target_os = "macos")'.dependencies] so Cargo merges the feature on macOS while Linux builds omit it cleanly.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughReorganizes Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Fixes a Linux-only startup hang in the Tauri app by avoiding an early Webview log target path that can deadlock during setup(), and adjusts Cargo feature configuration so tauri-build validation passes on non-macOS platforms.
Changes:
- Conditionally include
tauri_plugin_log::TargetKind::Webviewonly for macOS. - Move
tauri’smacos-private-apifeature into a macOS-only dependency section, keepingprotocol-assetin the base dependency.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
src-tauri/src/lib.rs |
Makes the log plugin targets platform-conditional to avoid Linux startup deadlock. |
src-tauri/Cargo.toml |
Splits tauri features by platform to satisfy tauri-build feature/allowlist validation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
|
@MareDevi Thanks for this. Gimme a few days to review and merge. |
|
@MareDevi Just realised this is like a 15-line diff 😅 Looks good - thanks 🙂 |
On Linux with WebKitGTK, the Webview log target causes app.emit() to deadlock during setup() because the webview process doesn't exist yet. The IPC socket registers with epoll but never receives a response, blocking forever on the first log::info!() call. Guard the Webview target with #[cfg(not(target_os = "linux"))]. Stdout and LogDir targets continue to work on all platforms. Ref: dannysmith/astro-editor#150 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Problem
On Linux (tested on Arch Linux with Wayland + WebKitGTK), running
pnpm run tauri devhangs permanently after:The app window never appears. The same hang occurs with
cargo rundirectly.Root Cause
Two separate issues, both Linux-specific:
1.
tauri_plugin_logWebview target deadlock (lib.rs)The
Webviewlog target callsapp.emit()internally on everylog::info!call. Duringsetup(), the WebKitGTK webview process does not yet exist. On Linux, this causes the underlying IPC socket to be registered with mio (Token(1), interests=READABLE) with no peer to write to it — the epoll event never fires andsetup()blocks forever.This was confirmed by bisecting with
eprintln!checkpoints: execution stops inside the firstlog::info!call and never returns.On macOS the webview initialisation order is different and this path is safe.
2.
macos-private-apiin base[dependencies](Cargo.toml)tauri-buildvalidates that themacos-private-apiCargo feature matches"macOSPrivateApi": truein the mergedtauri.conf.json. On macOS,tauri.macos.conf.jsonis merged in at build time and supplies that key. On Linux onlytauri.conf.json+tauri.linux.conf.jsonare merged — neither containsmacOSPrivateApi— so the build fails with:The existing comment states this feature is "a no-op on non-macOS", but
tauri-build's validation fires regardless of platform.Fix
src-tauri/src/lib.rs— restrict theWebviewlog target to macOS only using#[cfg(target_os = "macos")].StdoutandLogDirtargets continue to work on all platforms.src-tauri/Cargo.toml— movemacos-private-apifrom the base[dependencies]into[target.'cfg(target_os = "macos")'.dependencies]. Cargo merges features across sections, so macOS builds retain the full feature set (protocol-asset+macos-private-api) while Linux/Windows builds only getprotocol-asset, satisfyingtauri-buildon both platforms.Testing
Verified on Arch Linux (Wayland, WebKitGTK 4.1 + 6.0). The app now starts up fully and the window appears.
cargo clippyandcargo fmt --checkpass cleanly.Summary by CodeRabbit