Summary
On macOS, the Fn / Globe key (keyCode 63) is swallowed by WKWebView before it ever reaches the input method, so any IME feature triggered by holding Fn (e.g. voice input / push-to-talk shortcuts in Chinese input methods like 豆包输入法/DoubaoIme) silently fails inside every Wails app window, while the same IME works fine in native apps and Chromium apps.
Environment
- macOS 26.2, Apple Silicon (arm64)
- Wails app: Reasonix Desktop (Wails/WKWebView variant, v1.31.4,
com.wails.reasonix-desktop) — but this affects any Wails app on macOS
- IME: DoubaoIme (豆包输入法), voice shortcut bound to "hold Fn/Globe"
Observed behavior
| Target |
Pressing Fn (physical or remapped) while IME voice input is active |
| Native app (e.g. TextEdit, SwiftUI app) |
✅ IME receives the key, voice input starts |
| Chromium app (Chrome, Codex desktop) |
✅ works |
| Wails app (WKWebView) |
❌ IME never receives it — no reaction at all |
Typing in the Wails app works fine (keyDown path → NSTextInputContext → IME). The problem is specific to the bare Fn modifier event: it arrives as flagsChanged and is dropped.
Root cause (upstream WebKit)
WebKit's WebViewImpl::flagsChanged() explicitly filters keyCode 63 (Fn/Globe) and returns before calling interpretKeyEvent() (the call that hands the event to the current NSTextInputContext / IME):
Chinese IMEs commonly use "hold Fn/Globe to speak" as a voice shortcut, and hardware remappers (e.g. turning a Bluetooth remote's mic button into Fn) produce exactly this event, so both physical and remapped Fn fail.
Request
Please consider a macOS-side fix in Wails so Fn/Globe events are forwarded to the input context instead of being silently dropped, e.g. install a NSEventMaskFlagsChanged local monitor on the Wails window that, for keyCode 63, forwards the event to the current first responder's [inputContext handleEvent:event] while still passing the original event through to AppKit (per Apple's NSTextInputContext.handleEvent docs: https://developer.apple.com/documentation/appkit/nstextinputcontext/handleevent(_:)).
A WebKit-upstream fix would be "deliver Fn to the IME while still not generating a DOM keyboard event".
Minimal repro
- Install any Chinese IME that supports a "hold Fn to speak" voice shortcut (e.g. DoubaoIme) and bind its voice key to Fn/Globe.
- Open any Wails app, focus a text field, and make sure the IME is active.
- Hold Fn and speak → nothing happens.
- Repeat in TextEdit or Chrome → works.
Related
Summary
On macOS, the Fn / Globe key (
keyCode 63) is swallowed by WKWebView before it ever reaches the input method, so any IME feature triggered by holding Fn (e.g. voice input / push-to-talk shortcuts in Chinese input methods like 豆包输入法/DoubaoIme) silently fails inside every Wails app window, while the same IME works fine in native apps and Chromium apps.Environment
com.wails.reasonix-desktop) — but this affects any Wails app on macOSObserved behavior
Typing in the Wails app works fine (
keyDownpath →NSTextInputContext→ IME). The problem is specific to the bare Fn modifier event: it arrives asflagsChangedand is dropped.Root cause (upstream WebKit)
WebKit's
WebViewImpl::flagsChanged()explicitly filterskeyCode 63(Fn/Globe) and returns before callinginterpretKeyEvent()(the call that hands the event to the currentNSTextInputContext/ IME):Chinese IMEs commonly use "hold Fn/Globe to speak" as a voice shortcut, and hardware remappers (e.g. turning a Bluetooth remote's mic button into Fn) produce exactly this event, so both physical and remapped Fn fail.
Request
Please consider a macOS-side fix in Wails so Fn/Globe events are forwarded to the input context instead of being silently dropped, e.g. install a
NSEventMaskFlagsChangedlocal monitor on the Wails window that, forkeyCode 63, forwards the event to the current first responder's[inputContext handleEvent:event]while still passing the original event through to AppKit (per Apple'sNSTextInputContext.handleEventdocs: https://developer.apple.com/documentation/appkit/nstextinputcontext/handleevent(_:)).A WebKit-upstream fix would be "deliver Fn to the IME while still not generating a DOM keyboard event".
Minimal repro
Related