All JS-eval operations time out on macOS while /window/* responds (v0.1.3)

[RyanZRF]

Summary

On a Tauri 2 app with tauri-plugin-webdriver-automation = "0.1.3" registered behind cfg(debug_assertions), every WebDriver operation that requires evaluating JS in the WebView hangs indefinitely, while pure-Rust window operations respond instantly. This is a third symptom alongside #2 and #4, but with a distinct failure mode — no execute/sync ref-resolution issue (#2) and no mutex poisoning (#4); operations just never return.

Environment

• macOS 26.x (Apple Silicon)
• Tauri 2.9.5, wry 0.53.5, runtime-wry 2.9.3
• tauri-plugin-webdriver-automation = "0.1.3"
• tauri-webdriver-automation CLI v0.1.3 (tauri-wd)
• App config: macOSPrivateApi: true, devtools: true, csp: null
• Launched via the mcp-tauri-automation MCP server (which uses tauri-wd)

Reproduction

1. Launch the Tauri debug binary via tauri-wd — session creates successfully, plugin reports its dynamic port to tauri-wd:

   tauri_wd: Session ... created, plugin at http://127.0.0.1:NNNNN
   

2. Send a window-level request to the plugin — works immediately:

   $ curl -X POST http://127.0.0.1:NNNNN/window/handle -d '{}'
   "main"

3. Send any DOM/JS request — hangs forever (tried 60s timeout, still hangs):

   $ curl --max-time 60 -X POST http://127.0.0.1:NNNNN/element/find \
       -H "Content-Type: application/json" -d '{"using":"css","value":"body"}'
   # (no response)

   Also hangs:

   • POST /element/find (any selector, including html, body)
   • POST /screenshot (10s timeout via MCP)
   • W3C GET /session/{id}/url via tauri-wd port 4444

4. Even the simplest execute/sync body hangs:

   $ curl --max-time 60 -X POST http://127.0.0.1:4444/session/{id}/execute/sync \
       -d '{"script":"return document.title;","args":[]}'

What works vs. what hangs

Endpoint	Result
/window/handle, /window/rect	✅ instant
/element/find (any selector)	❌ hangs > 60s
/element/text, /element/click	❌ hangs > 60s
/script/execute (simple)	❌ hangs > 60s
/screenshot	❌ hangs > 60s

This perfectly bifurcates around "does this command require evaluating JS in the WebView?". Window state is pure Rust, works. Anything touching the WebView's JS environment never responds.

Hypothesis

The app's dist/index.html synchronously loads ~10 external CDN scripts (Tailwind CDN, FontAwesome, Mermaid, Chart.js, etc.). In our network environment these CDNs are sometimes slow/unreachable. If the WebView's main JS thread is blocked on these blocking <script src="https://..."> tags before reaching interactive state, every JS eval roundtrip would hang waiting for the thread.

If true, the issue isn't strictly a plugin bug — but the plugin should probably surface this state somehow (timeout with a meaningful error rather than indefinite hang). Right now there's no way for clients to distinguish "plugin broken" from "page still loading" from "page deadlocked".

Requests

1. Add a load-state probe / timeout so JS-eval calls fail fast with a meaningful error if the WebView hasn't reached interactive state.
2. Document known network constraints — if external CDN scripts in the page can block the plugin indefinitely, mention it in the README so users know to strip / preload them in test builds.
3. Optional: a /status/webview endpoint returning whether the JS-eval bridge is responding (a tiny test eval with a 500ms timeout).

Happy to provide a minimal repro repo if useful, and to help test fixes.

[tukuyomil032]

I'm having a similar problem in my environment