fix(runtime-wry): add response channel to CreateWindow for HWND readiness#14915
Open
npiesco wants to merge 1 commit intotauri-apps:devfrom
Open
fix(runtime-wry): add response channel to CreateWindow for HWND readiness#14915npiesco wants to merge 1 commit intotauri-apps:devfrom
npiesco wants to merge 1 commit intotauri-apps:devfrom
Conversation
…ness Message::CreateWindow was fire-and-forget: send_user_message dispatched the creation request to the event loop thread and returned immediately. On Windows, downstream code that called hwnd() could race against the event loop inserting the window into the window map. Add a Sender<Result<()>> to Message::CreateWindow. The event loop handler now signals Ok(()) after inserting the window, and the caller blocks on the receiver, guaranteeing the HWND exists before create_window returns. Includes 4 unit tests for the response channel contract: success propagation, error propagation, blocking semantics, and compile-time type assertion. Ref: https://github.com/npiesco/wry-arm64-deadlock (minimal reproduction)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a
Sender<Result<()>>toMessage::CreateWindowso the caller blocks until the window's HWND is registered on the event loop thread, fixing a race condition wherecreate_windowreturned before the window was usable.Closes #14914. Related: tauri-apps/wry#1665, tauri-apps/wry#1666.
Problem
create_windowsends aMessage::CreateWindowto the event loop via the proxy and returns immediately. The event loop thread then creates the window, registers the HWND in the window map, and installs WebView2 but the caller has already returned frombuild()and may attempt to use.hwnd()or other window methods before the HWND is available.This race was discovered while fixing the ARM64 WebView2 deadlock (tauri-apps/wry#1665): even after fixing the wry-level deadlock, the Tauri runtime would intermittently fail because
create_windowreturned aWebviewWindowwhose HWND wasn't yet registered.On x86/x64 the race window is small enough that it rarely triggers, but on ARM64 (Snapdragon X Elite) the different timing makes it deterministic.
Solution
Add a oneshot
Sender<Result<()>>to theMessage::CreateWindowvariant:create_window): Creates astd::sync::mpsc::channel(), attaches the sender to the message, sends it to the event loop, then blocks onrx.recv()until the event loop confirms completion.Message::CreateWindowmatch arm): After the window is created and registered in the window map, sendsOk(())through the channel. On error, sendsErr(...).This ensures
build()does not return until the HWND is registered and ready.Testing
create_window_message_carries_senderverifies theSenderis included in the message variantcreate_window_response_channel_successverifiesOk(())flows through the channelcreate_window_response_channel_errorverifies errors propagatecreate_window_response_channel_blocks_callerverifies the caller blocks until the handler respondscargo test -p tauri-runtime-wrypasses (4 passed, 0 failed)cargo clippy -p tauri-runtime-wryclean (0 warnings)Minimal Reproduction
https://github.com/npiesco/wry-arm64-deadlock
mainbranch: exhibits the race (and the upstream wry deadlock)fix/vendored-wry-tauribranch: includes both fixes (this PR + fix(windows): use CoWaitForMultipleHandles for ARM64 WebView2 deadlock wry#1666)Dependency
This fix is independent of tauri-apps/wry#1666 (the CoWaitForMultipleHandles fix), but both are needed together to fully resolve the ARM64 deadlock + HWND race. They can be merged in either order.