Resolve the text input shortcut layout at runtime on wasm - #25395
Open
Cyannide wants to merge 1 commit into
Open
Resolve the text input shortcut layout at runtime on wasm#25395Cyannide wants to merge 1 commit into
Cyannide wants to merge 1 commit into
Conversation
COMMAND and WORD were compile-time consts keyed on cfg!(target_os) -- correct on native, wrong on wasm32, where target_os is "unknown" and one binary serves every host OS. macOS browser users got the Ctrl layout: Cmd-C/X/V/A matched no arm and were silently dropped, word navigation wanted Ctrl instead of Option, and the macOS-only arms (Cmd-arrow line start/end, Cmd-up/down text start/end) were cfg'd out entirely. mac_host() keeps the cfg! answer off-wasm and asks the browser once (navigator.platform, UA fallback, cached in a OnceLock). The layout consts become locals and the affected patterns become guards; arm order and native behavior are unchanged, and wasm now picks the same arms a native build of the host OS would. Fixes bevyengine#25340 (the copy/cut/paste half of it; the Chrome permission prompt on paste is a separate issue in bevy_clipboard/winit).
kfc35
approved these changes
Aug 13, 2026
kfc35
left a comment
Contributor
There was a problem hiding this comment.
This fixes the issue for me on duck duck go! Nice!!!
And the fix itself looks good to me
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.
Objective
COMMAND and WORD were compile-time consts keyed on
cfg!(target_os)-- correct on native, wrong on wasm32, where target_os is "unknown" and one binary serves every host OS. macOS browser users got the Ctrl layout: Cmd-C/X/V/A matched no arm and were silently dropped, word navigation wanted Ctrl instead of Option, and the macOS-only arms (Cmd-arrow line start/end, Cmd-up/down text start/end) were cfg'd out entirely.Solution
mac_host()keeps thecfg!answer off-wasm and asks the browser once (navigator.platform, UA fallback, cached in aOnceLock). The layout consts become locals and the affected patterns become guards; arm order and native behavior are unchanged, and wasm now picks the same arms a native build of the host OS would.Fixes #25340 (the copy/cut/paste half of it; the Chrome permission prompt on paste is a separate issue in bevy_clipboard/winit).
Adds a wasm-only
web-sysdependency (Window+Navigator) tobevy_ui_widgets.Testing
wasm app; macOS browser testers confirmed Cmd-A/C/X/V went from silently
dropped to working, with Option-arrow word nav behaving like a native mac
build. Linux/Windows browsers keep the Ctrl layout.
old const arms one for one, same order.
cargo checkand clippy, x86_64 and wasm32-unknown-unknown.multiple_text_inputsexample aswasm and try Cmd-C/V from a Mac browser (as in
EditableTextCopy / Paste does not work on Web targets #25340).