scan_code and virtual_key_code are swapped

[Woyten]

https://github.com/rust-windowing/winit/blob/master/src/platform_impl/web/web_sys/event.rs considers event.key_code()/event.char_code() to be the scan_code of the KeyboardInput event and event.code() to be the virtual_key_code of the KeyboardInput event while it should be the other way around.

How to verify yourself: Use the links given below and a German keyboard layout and press the German z key

• event.key_code()/event.char_code() will return 122 (the ASCII of z) i.e. the virtual meaning of the key
  • https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_event_key_keycode
  • https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_event_key_charcode
• event.code() will return KeyY i.e. the physical key location
  • https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_event_key_code

Demonstration of workaround in my personal project: https://github.com/Woyten/tune/commit/38b7ecd4841083bfb8d86440ee8d9fa4f73f52aa and https://github.com/Woyten/tune/commit/fcec2d38545ed0fdd76fd8a5b6c242095522f1ca

[Woyten]

@madsmtm I would like to contribute to winit by fixing this problem. Is that okay or is there some impediment like s.o. already working on it or an opposite opinion / vision regarding this topic?

[madsmtm]

I've no idea, the keyboard model is not something I've looked at at all.

See this meta issue: https://github.com/rust-windowing/winit/issues/1806, the fix may be present somewhere in those PRs already. Though if the fix is as simple as it sounds, your could try making a PR to fix it, though a big issue right now is that we don't have a WASM maintainer to approve it at the moment (see Testers and Contributors table), so not sure that would get you anywhere either.

[maroider]

The only sane keyboard input API on the web is fundamentally incompatible with winit's current keyboard API.

I unfortunately cannot give you an ETA on when #1888 (and thus a reasonable way of doing what you want to do) will get merged into the new-keyboard branch.

[Woyten]

@maroider What about an imperfect but less broken WASM implementation? I could do the following:

• event.code() is mapped to the scan code that was originally emitted by the keyboard. E.g. "KeyA" is mapped to scan code 30, KeyS to 31 and so on. As far as I can tell the scan codes are the same for all standardized physical keyboards under each platform.
• event.key_code() is mapped to the corresponding VirtualKeyCode via its ASCII number s.t. 65 becomes VirtualKeyCode::A, 66 becomes VirtualKeyCode::B and so on. We could even map the modifier keys on a best-effort basis, e.g. 17 is mapped to VirtualKeyCode::LControl (or VirtualKeyCode::RControl, they are indistinguishable which should be reflected in the VirualKeyCode enum in my opinion) .

I know this is not a bullet-proof solution but the current implementation is broken in a way which prevents projects like Nannou from delivering a first-class WASM experience. The biggest impediment probably is the modifiers state not being handled correctly. As I said: I would invest some time to help making the implementation less broken.

[kchibisov]

Fixed on master.