[bug] macOS: third-party IME drops the first keystroke inside the WebView (Safari with the same IME is unaffected)

[zanyatta]

Describe the bug

Describe the bug

On macOS, typing with a third-party input method inside a Tauri WebView loses
the first keystroke. Pressing Shift+; with the WeChat input method (微信输入法 /
WeType), which should emit the full-width colon ：, produces nothing. Pressing
it a second time emits the character. This happens every time — not once per
window, not once per session.

The built-in "Pinyin – Simplified" input method is unaffected in the same app,
in the same field.

The part that narrows it down

Safari on the same machine, on the same page, with the same input method, is
not affected. Safari is also WebKit, so this does not look like a WKWebView
text-input bug — the difference is the hosting window/view, which points at tao
or wry rather than WebKit itself. Feel free to transfer this issue if that is
where it belongs.

What I ruled out before filing

• Our own JavaScript. Every keydown listener in the app was audited. Only
  Escape, Tab and Enter are handled, and the Enter path is already
  IME-aware (isComposing plus the legacy keyCode === 229 fallback). Nothing
  calls preventDefault on the key in question.
• Injected scripts. The app's initialization_script contains no key
  handling at all.
• AppKit work the app does. A titlebar accessory view controller (secondary
  windows only) and NSNotificationCenter observers for fullscreen transitions.
  Neither touches the responder chain of the main window's content view.
• Secure Input. Not enabled — verified with
  ioreg -l -w 0 | grep SecureInput while the app was running and focused. This
  was the strongest candidate, since Secure Input blocks third-party IMEs while
  leaving Apple's own ones working, but it is off.

Reproduction

1. Install the WeChat input method (WeType) on macOS and select it.
2. Open any Tauri app with a text input in the WebView.
3. Press Shift+;.

Expected: ： is inserted.
Actual: nothing is inserted. Pressing Shift+; again inserts it.

Expected behavior

No response

Full tauri info output

[✘] Environment
    - OS: Mac OS 15.5.0 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✘ Xcode: not installed!
    ✔ rustc: 1.94.0 (4a4ef493e 2026-03-02)
    ✔ cargo: 1.94.0 (85eff7c80 2026-01-15)
    ✔ rustup: 1.29.0 (28d1352db 2026-03-05)
    ✔ Rust toolchain: 1.94.0-aarch64-apple-darwin (overridden by 'rust-toolchain.toml')
    - node: 24.11.0
    - pnpm: 10.12.1
    - yarn: 1.22.22
    - npm: 11.6.1

[-] Packages
    - tauri 🦀: 2.11.5
    - tauri-build 🦀: 2.6.3
    - wry 🦀: 0.55.1, (outdated, latest: 0.56.1)
    - tao 🦀: 0.35.3, (outdated, latest: 0.37.0)

[-] Plugins

[-] App
    - build-type: build
    - CSP: unset
    - frontendDist: ui

Third-party IME version: WeType (微信输入法) 2.2.3.

Stack trace

Additional context

Question

tauri info reports tao and wry as outdated, and tao 0.36.0's changelog
mentions a refactor of the macOS keyboard internals. Would that be expected to
address this? tauri 2.11.5 pins tao 0.35.3, so cargo update will not move it —
we cannot test 0.36+ without a [patch.crates-io] override. Happy to run that
experiment if it would be useful, and happy to add any instrumentation you want
on our side.

I could not find an existing issue for this on macOS; tauri #15436 looks like
the Windows/WebView2 equivalent.