macOS: Window becomes active but WKWebView is not first responder (keyboard input ignored until click)

[yuruko]

On macOS, after the app/window gains focus (e.g. Cmd+Tab back to the app), the window looks active but the embedded
WKWebView does not reliably become the first responder. As a result, keyboard events are not routed into the webview
until the user clicks inside it.
This appears to be a focus/responder-chain issue across:
Tauri -> Tao -> Wry -> WKWebView (macOS).

1. Build/run a Tauri 2.x app on macOS with an input/textarea in the webview.
2. Switch to another app (Cmd+Tab).
3. Try typing immediately.

Expected behavior

Typing should be directly captured by WKWebView, not make the 'invalid focus' MacOS sound.

Actual behavior

The window is focused/active, but the webview does not receive keyboard events until a mouse click occurs inside it.

Environment

• macOS: 15.6.1
• CPU: M1
• Tauri (Rust): 2.10.2
• @tauri-apps/api: 2.10.1
• wry: 0.54.1
• tao: 0.34.5
• rustc: 1.92.0

Notes / suspected root cause

WKWebView is not automatically set as the first responder when the NSWindow becomes key / app becomes active, so
keyboard events are not routed to the WKWebView until a click causes responder activation.

Possible solution

1. Native macOS workaround (tao #208 style):
   Explicitly set WKWebView as first responder on window activation, e.g. makeFirstResponder:nil then
   makeFirstResponder:WKWebView on NSWindowDidBecomeKeyNotification / NSApplicationDidBecomeActiveNotification.

Related / prior art

• tauri#5464
• tauri#5662
• tauri#2397
• tao#208
• wry#637
• wry#184
• Tauri v2 Webview API docs for setFocus()

[yuruko]

0.9.9 may have resolved this, but not 100% certain.

[yuruko]

Issue not resolved.

[yuruko]

One instance of the issue was resolved. There may be more.