Describe the bug
On Windows, InnerWebView::attach_ipc_handler unconditionally injects the window.ipc bridge script via Self::add_script_to_execute_on_document_created, which waits synchronously (wait_for_async_operation) for the cross-process AddScriptToExecuteOnDocumentCreated completion — even when attributes.ipc_handler is None:
https://github.com/tauri-apps/wry/blob/dev/src/webview2/mod.rs (see attach_ipc_handler, the add_script_to_execute_on_document_created call before ipc_handler.take())
Because this runs right after controller creation — while the renderer process is still booting — the round-trip is expensive. Phase-instrumented on wry 0.56.1 (timestamps around each step of new_in_hwnd, release build, Windows 11, WebView2 Evergreen 151, warm profile): attach_ipc_handler takes 96–109 ms on the UI thread across samples, while every other settings/handler registration step is ~0.3 ms combined.
For embedders that never use window.ipc, that is ~100 ms of unnecessary UI-thread blocking during every webview build. (For paint-bound hello-window benchmarks it largely overlaps renderer startup, so it may not show up in time-to-first-paint — but it does block the UI thread and delays anything else the embedder wants to do after build().)
Possible fixes
- Skip the bridge injection when
attributes.ipc_handler is None (matches the docs' contract that window.ipc.postMessage exists for the ipc handler), or
- inject it with the async completion-handler form instead of
wait_for_async_operation, so the wait leaves the UI thread.
Happy to provide the raw phase timestamps if useful.
Environment
- wry 0.56.1, tao 0.35.3
- Windows 11 (10.0.26200), WebView2 Evergreen 151.0.4129.86
- release build, warm user-data folder
Describe the bug
On Windows,
InnerWebView::attach_ipc_handlerunconditionally injects thewindow.ipcbridge script viaSelf::add_script_to_execute_on_document_created, which waits synchronously (wait_for_async_operation) for the cross-processAddScriptToExecuteOnDocumentCreatedcompletion — even whenattributes.ipc_handlerisNone:https://github.com/tauri-apps/wry/blob/dev/src/webview2/mod.rs (see
attach_ipc_handler, theadd_script_to_execute_on_document_createdcall beforeipc_handler.take())Because this runs right after controller creation — while the renderer process is still booting — the round-trip is expensive. Phase-instrumented on wry 0.56.1 (timestamps around each step of
new_in_hwnd, release build, Windows 11, WebView2 Evergreen 151, warm profile):attach_ipc_handlertakes 96–109 ms on the UI thread across samples, while every other settings/handler registration step is ~0.3 ms combined.For embedders that never use
window.ipc, that is ~100 ms of unnecessary UI-thread blocking during every webview build. (For paint-bound hello-window benchmarks it largely overlaps renderer startup, so it may not show up in time-to-first-paint — but it does block the UI thread and delays anything else the embedder wants to do afterbuild().)Possible fixes
attributes.ipc_handlerisNone(matches the docs' contract thatwindow.ipc.postMessageexists for the ipc handler), orwait_for_async_operation, so the wait leaves the UI thread.Happy to provide the raw phase timestamps if useful.
Environment