Open core-ai-bot opened 3 years ago
Comment by RaymondLim Thursday Jan 08, 2015 at 18:19 GMT
I think it should be a high priority issue since I can reproduce it in some IMEs (2-Set Korean, Zhuyin and Zhuyin - Eten). But I believe the issue is there with older releases (as fas as sprint-15). So set it to medium priority. The fix for it is pretty easy. We can prevent from assigning keyIdentifier property by checking key
is not one of the A to Z characters. ie. replacing if (ident)
with if (ident && /[^A-Z]/.test(key))
Issue by patricio-marrone Thursday Jan 08, 2015 at 01:36 GMT Originally opened as https://github.com/adobe/brackets/issues/10329
Steps
Result
Nothing happens. The shortcut does not work.
Expected result
File should have been saved, just as when using native menus
Version
This was tested on brackets, taken from git SHA 5542986f5ffcb81e0061e5f7c727fae8df9b00ac
Posible cause
KeyBindingManager is using the keyIdentifier property of the keyboard event whenever possible. In Windows, when the S key is pressed, both the keyIdentifier property and the keyCode get changed to the corresponding S character codes; while on Mac OS X, the keyIdentifier remains pointing to the Korean character and only the keyCode and which properties of the keyboard event get changed to the 'S' code. This leads to inconsistent behavior when using some shortcuts in a group of non-latin keyboards. In this case, Ctrl+S on a Korean layout was shown as an example.
In the captured image below, it can be seen that the 'key' value was interpreted the same way as in the native menu shortcut (S), but it will be replaced in the following steps by the corresponding Korean character.