Wrong Shortcut shown for View->Zoom In

[luca3s]

In the browser the Menu bar shows the shortcut for Zoom In as Cmd+=, while the correct shortcut is Cmd+(+). The web app reacts to the correct shortcut.

On mac desktop the shortcut is shown as Cmd+*. But here it also reacts to Cmd+* instead of the correct Cmd+(+).

[Keavon]

The shortcut is actually Ctrl=. There is no + key on a keyboard (excluding the numpad). But it is probably clearer to special-case this and show a "+" instead of an "=" or the verbose "Numpad +" here.

[luca3s]

There is no + key on a keyboard (excluding the numpad).

On german keyboards there is a + but no =. = can be created by typing shift 0. I don't know if you have access to the keyboard layout from the browser, but if you would make that dependent on it, it would make sense to me.

[Keavon]

There are three types of keyboard input:

• The scan codes, these are the same across all keyboards in the world, every other language maps its keys to the spatial locations of US keyboard keys (even if the key labels don't correspond to the scan codes); there is no such thing as a "+" key
• The letters marked on the physical key caps; in this case, certain keyboards might have a "+" key, but the web provides no API to access this but desktop APIs do
• The unicode characters typed by pressing the keys, which doesn't have to correspond to what's marked on the key caps and will vary if modifiers like Shift and AltGr are pressed (or Option on Mac)

Because web APIs only give us access to the first and last options, we don't currently base the keys on the middle option; instead, we aim to approximate our own interpretation of sort of the middle option using some heuristic combination of the first and last options. This can be refactored in the future to better support the full information that desktop APIs can provide us, but that refactor will need to work in concert with the web approach to maintain graceful degradation on web (and then there are various combinations of browser-reserved keys you can't use on web in different situations that we also need to provide dynamic fallbacks and graceful degradation for, also; plus Mac has its variants of OS reserved keys we similarly need to work around).

[luca3s]

So in this case you were using the physical keycode to detect the shortcut, which for german keyboards lead to a difference between shown key and the key the code reacted to. Interesting.

[Keavon]

That's the situation on web. Now that we have to use native APIs to feed CEF with its inputs to then convert into JS's APIs as the scan codes and unicode character outputs, we basically need to do whatever Chrome (the browser, not CEF) is doing on each platform's input APIs. But it sounds like that is highly undocumented, hence the confusion.

If I understand it correctly, we are routing all input events through CEF -> JS -> Wasm -> back to native Rust (@timon-schelling please correct me if I'm wrong), which means our actual native Rust code is still being handled with the same JS input routing as we have on web, including its limitations about not being able to retrieve the letters marked on the physical key caps and having to use our heuristic approximation of that. But while that's not ideal to be limited by the web API's limitations in the long term, it helps simplify things for now while we aim to get this initial release out the door knowing that the web's behavior is the reference behavior and any deviations from it result from difficulties in mapping platform native input APIs to CEF's needed inputs.