Fix hotkey capture corrupting Option combos into unparseable accelerators (v0.1.17)#21
Merged
Merged
Conversation
…tors (v0.1.17)
Live log evidence from the user's own session:
Global shortcut registration failed ... error=Found empty token while
parsing hotkey: Alt+\u{a0}
General.tsx's toAccelerator() built the accelerator from
KeyboardEvent.key — the *composed* character. macOS recomposes many keys
under Option into a different Unicode character than what's printed on the
keycap: Option+Space's key is a non-breaking space (U+00A0), not a plain
' '. The capture UI displayed 'Alt+Space' but persisted 'Alt+<NBSP>' to
settings.json — invisible until the next boot's registration attempt
rejected it outright. The 0.1.15/0.1.16 self-heal recovered the hotkey back
to the default afterward (confirmed: settings.json already reads
Alt+Space again), but the underlying capture bug means rebinding to any
Option combo reproduces it every time.
toAccelerator now resolves letters/digits/Space from KeyboardEvent.code
(the physical key, unaffected by modifier composition) instead of key.
Verified live in a real browser: simulated the exact Option+Space event
macOS actually sends (code: 'Space', key: '\u00A0') and confirmed it now
captures as 'Alt+Space'; same for Option+C (key: 'ç') capturing as 'Alt+C'.
Bump to v0.1.17, changelog entry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause — from the user's own live log
settings.json'stoggle_shortcutwas"Alt+\u00A0"— Alt followed by a non-breaking space (U+00A0), not the literal string"Space".General.tsx'stoAccelerator()built the accelerator fromKeyboardEvent.key(the composed character). macOS recomposes many keys under Option into a different Unicode character than what's printed on the keycap: Option+Space'skeyis U+00A0, not" "; Option+letters compose accented characters (Option+C →"ç"). The capture UI displayed "Alt+Space" (fine, that's a static label) but the value it persisted was built from the corrupted composed character — invisible until the next registration attempt rejected it outright.The 0.1.15/0.1.16 boot-time self-heal already recovered the hotkey back to the default (confirmed:
settings.jsonon the user's machine already readsAlt+Spaceagain after that log), but the underlying capture defect means rebinding to any Option combo reproduces the exact same corruption every time.Fix
toAcceleratornow resolves letters/digits/Space fromKeyboardEvent.code(the physical key, unaffected by modifier-driven composition) instead ofkey, via a newcodeToAcceleratorKeyhelper. Falls back to the existingkey-based handling only for keys Option can't recompose (arrows, function keys, Escape, etc.), preserving all prior behavior for those.Verification
tsc --noEmitclean.code: "Space", key: "\u00A0") — captured asAlt+Space, not corrupted.key: "ç") — captured asAlt+C.src-tauri/tauri.conf.json+Cargo.toml/Cargo.lockto 0.1.17, added CHANGELOG entry.