Internationalized Keyboard Issues #52
Description
So I have come across two issues that appear with regards to international keyboard layouts.
The bug appears to manifest itself in the characterFromEvent method.
Issue 1:
The first issue is kind a logical one, so I would not be surprised if you marked it as a wontfix.
If we take the following bind: ctrl+/, it appear innocuous enough, however many international keyboard layouts put / on a number key, accessible via shift (for example, on a Portuguese keyboard layout, / is accessibly using shift on the the 7 key).
This keybind will no longer work on international keyboards since they require shift to be held in order to access the / key. This could be a slippery support to allow keybinds to smartly take into account the various layouts.
Issue 2:
I can sort of work around the previous issue by adding shift as a secondary bind: ['ctrl+/', 'ctrl+shift+/']. However this only works on Mac, PC will still not trigger the callback.
I did some console sniffing and found that while the KeyboardEvent accurately reports the / in event.key on both Windows and Mac, however the logic to determine the key actually reports 7. You guys heavily depend on e.which, which on Mac (no pun intended) reports 191 and on Windows reports 55.
I guess the first question would be, how come you guys don't use event.key? I assume there must've been some older browser bug, or something that makes that API unreliable? Or perhaps some other reason? Anyways, in this case, I really need to be agnostic regarding international layouts since I develop an application that is heavily used internationally, Discord.