fix(v3): offer the Fn/Globe key to the input method on macOS - #6035
fix(v3): offer the Fn/Globe key to the input method on macOS#6035taliesin-ai wants to merge 1 commit into
Conversation
The Fn/Globe key arrives as a modifier change rather than a key press, and WebKit drops keyCode 63 in WebViewImpl::flagsChanged() before it reaches interpretKeyEvent(). The current input method therefore never sees it, and an input method that binds a shortcut to holding Fn - push-to-talk voice input is the common one, and hardware remappers produce the same event - does nothing at all inside a Wails window while working in native and Chromium applications. Nothing in Wails handled flagsChanged, so there was no code path to fix; this adds one. A local event monitor, alongside the two this file already installs for mouse events, offers a keyCode 63 modifier change to the first responder's input context. The event is returned unchanged either way, so AppKit's own handling is untouched and no DOM keyboard event is synthesised - the page still does not see Fn, which is both the existing behaviour and the right one. The monitor ignores every other key code, and events belonging to windows that are not ours. Reported in #6033, which also proposed this approach and cited the NSTextInputContext.handleEvent documentation for it. Verified here: the build and vet are clean, the test suite passes, and sending real Fn presses to a running application changes nothing else - key bindings fire before and after, and the application does not crash. What could not be verified here is the symptom itself, which needs an input method with a hold-Fn voice shortcut bound. Synthesising the event proves delivery, not that the input method acts on it, so the reporter should confirm before this is trusted. Claude-Session: https://claude.ai/code/session_01WP7MWnMpQDT2WB7CPLWbqr
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. WalkthroughThe macOS application now monitors Fn/Globe modifier events with key code 63. Eligible Wails webview events are forwarded to the first responder’s text input context while the original event continues through AppKit. ChangesFn/Globe input forwarding
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized macOS change forwards the Fn/Globe modifier to the input method while preserving AppKit’s original event handling. No actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant LocalMonitor
participant WailsWebView
participant FirstResponder
participant NSTextInputContext
LocalMonitor->>WailsWebView: Receive flagsChanged event
WailsWebView->>FirstResponder: Resolve first responder
FirstResponder->>NSTextInputContext: Forward Fn/Globe event
NSTextInputContext-->>LocalMonitor: Process event
LocalMonitor-->>WailsWebView: Return original event
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Linked Issues checkExplanation The implementation addresses issue Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1 files. Full details: Description checkExplanation The description provides the issue context, implementation details, testing results, and remaining validation status. It does not complete the template checkboxes or include ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes #6033 — pending confirmation from the reporter, see Testing.
The problem
The Fn/Globe key arrives as a modifier change, not a key press. WebKit drops
keyCode 63inWebViewImpl::flagsChanged()before it reachesinterpretKeyEvent(), so the current input method never sees it. An input method that binds a shortcut to holding Fn — push-to-talk voice input is the common one, and hardware remappers produce the same event — does nothing at all inside a Wails window, while working in native and Chromium apps.Nothing in Wails handled
flagsChangedat all, so there was no existing code path to correct; this adds one.The change
A local event monitor, alongside the two
application_darwin.goalready installs for mouse events, offers a keyCode 63 modifier change to the first responder's input context:The event is returned unchanged either way, so AppKit's own handling is untouched and no DOM keyboard event is synthesised — the page still doesn't see Fn, which is both the existing behaviour and the right one. The monitor ignores every other key code, and events belonging to windows that aren't ours.
This is the approach @1939869736luosi proposed in the issue, citing
NSTextInputContext.handleEvent.inputContextis declared onNSView, notNSResponder, and the first responder isn't necessarily a view — hence theisKindOfClass:check, which also keeps the cgo build free of warnings.Testing
Verified: build and
go vetclean,pkg/applicationtests pass, and sending real Fn presses to a running application changes nothing else — key bindings fire before and after, and nothing crashes. So the regression risk (swallowing events, or breaking normal keyboard handling) is covered.Not verified: the symptom itself. Reproducing it needs an input method with a hold-Fn voice shortcut bound, which I don't have. Synthesising the event proves delivery, not that the input method acts on it.
@1939869736luosi — would you be able to build this branch and confirm your IME's Fn voice shortcut now works inside a Wails window? I'd rather not have this merged on the strength of reasoning alone.
Summary by CodeRabbit