Bug 5162 - Can't access keyboard shortcuts from non-Latin keyboard
Summary: Can't access keyboard shortcuts from non-Latin keyboard
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Shell ()
Version: 3.0.x
Hardware: PC Mac OS
: High normal
Target Milestone: 15.4
Assignee: Cody Russell
: 625 1441 33645 45001 57123 58904 ()
Depends on:
Reported: 2012-05-18 02:42 UTC by Alex Sinm
Modified: 2017-08-22 12:53 UTC (History)
25 users (show)

Tags: gtk,15.4candidate
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Alex Sinm 2012-05-18 02:42:04 UTC
Cmd-C,V,Z,S not working when switched to alternate (not the english one) keyboard input source.
Comment 1 Mike Krüger 2012-05-18 02:47:30 UTC
Does the keyboard input in the text editor work ?
I suspect it's something with the command system since the cut/copy/paste actions are bound there.
Comment 2 Alex Sinm 2012-05-18 02:52:48 UTC
Yes, input works, but not shortcuts. If i change e.g. copy shortcut to the russian CMD-C, it works only when the russian input source is active. I think english shortcuts should work in any language, mapping keys not chars. Just like it works in any other editor app.
Comment 3 Mikayla Hutchinson [MSFT] 2012-05-18 14:18:41 UTC
I'm not sure what you're asking for here, and since I'm not familiar with using Russian keyboard layouts I cannot test it. Could you explain in some more detail?

If I understand correctly, you're saying:
* you switch between some Russian layout and some English layout
* Cmd-S works in English, but not Russian.
* If you rebind Cmd-S while in Russia, it works in Russian but not in English.
* You expect the same keypress to perform the shortcut in both layouts.

What's not clear to me:
* Which Russian and English layouts are you using?
* When you do "Cmd-S" in both layouts, are these the same physical keys?
* What is "Cmd-S" in Russian layout? Is it actually a Latin "s" character, or some Cyrillic character?
* How is MonoDevelop's keybinding editor interpreting your inputs?

It's necessary for us to perform keyboard mapping so that the user can actually type the shortcut shown in the menu, instead of having to mentally remap it to an English layout - for example, Cmd-A with the French AZERTY layout.

What you're asking for might be possible if the command system tried to fall back to interpreting the keycode using some English layout if it could not be resolved using the active layout. Not sure what the English layout should be though... US? International?

I'm a little skeptical this is the correct solution as this might cause some surprise if a user accidentally types some keys that don't match a shortcut, but and it triggers a command via the English layout.

Do you know how apps on MacOS/Window usually handle this?
Comment 4 Alex Sinm 2012-05-18 15:16:10 UTC
* I'm switching between U.S. and Russian-PC layouts; "Use the same one in all documents" keyboard option set.
* Cmd-S works in English, but not Russian. Exactly. This is the same physical key but very different chars.
* If I rebind Cmd-S while in Russian, it works in Russian but not in English. Yes. Keybinding editor interprets it as a char code while in russian.
* I expect the same keypress to perform the shortcut in both layouts. 

I don't remember any application where i could change bindings and have to change layouts to perform binded action.

I've just tried to remap CMD-S to CMD-L in Netbeans and RubyMine:
* They show CMD-L when user remaps, regardless of current layout
* They handle CMD-L, regardless of current layout. Physical english L, no matter it is actually Д in russian.

I'm not sure but think osx/win apps usually map key-codes rather than char-codes. I don't mind french impact on keymaps here but i was REALLY frustrated last year using raw AZERTY without any corresponding QWERTY in Paris :).  In Russia we use keyboards where we have both cyrillic and english glyphs on buttons. In every app shortcuts in menu displayed in english, but work in any layout.
Comment 5 Mikayla Hutchinson [MSFT] 2012-05-18 18:07:48 UTC
We only remap the input, not the bindings. So, to use AZERTY as an example again - we would display Select All as Cmd-A, not Cmd-Q. When you type Cmd-A with the A of AZERTY, it would trigger Select All (Cmd-A), not Quit (Cmd-Q). This means that the menu labels and the actual keyboard are consistent.

Apple's DefaultKeyBinding.dict system appears to be character-based, FWIW. I have no idea how it deals with different layouts.

Anyway, I can think of a few ways to fix this, none ideal:

a) the keybinding system could always use an english layout for key mapping. This would be inconsistent with the actual keyboard in many cases, so quite confusing, e.g. Cmd-A would correspond to the keys labelled Cmd-Q on AZERTY.

b) the keybindings could be remapped from english onto the current layout, and displayed that way. This is difficult to implement, and they might not make sense, e.g. Select All would become cmd-Q in AZERTY.

c) The keybinding system wouldn't change the way it stored or displayed keys. When interpreting input keys, it would try to resolve them to bindings using the active keymap, and if that failed, then it would try again using the english keymap. This might be rather non-obvious, and we'd have to assume that our choice of english layout matched what the user expected.

d) We could special case certain known layouts that are known to be used switched to/from english, and use the english keymap for resolving shortcuts on those layouts. This would mean we could fix specific cases like yours without risking breaking other causes. But it might still have the disadvantages of (a), for numbers, punctuation etc.

I know it might sounds like I'm hung up on AZERTY, but I'm just using it as a simple example. There are many other keyboard layouts that move punctuation around, etc.
Comment 6 Alex Sinm 2012-05-21 06:54:46 UTC
Something related - https://trac.gajim.org/ticket/1503 + look at related links there.
Comment 7 Mikayla Hutchinson [MSFT] 2012-11-14 18:27:31 UTC
*** Bug 625 has been marked as a duplicate of this bug. ***
Comment 8 Mikayla Hutchinson [MSFT] 2012-11-14 18:27:50 UTC
*** Bug 1441 has been marked as a duplicate of this bug. ***
Comment 9 Ivan 2013-07-11 21:11:39 UTC
Moving from MonoDevelop to Xamarin, I sincerely hoped for a fix for this very annoying issue. Seems like both applications bind their hotkeys to English keyboard layout, which is not something you would expect since no other application that I know has this issue. 

I would be happy to provide whatever debug information needed to help solve this issue. Judging by the duplicate bug reports, two years have passed, but still no end in sight for what is a major bug affecting all users who have several keyboard layouts (input sources).
Comment 10 Mikayla Hutchinson [MSFT] 2013-08-15 19:37:59 UTC
See comment 5, I think (c) is the way to go, but I can't find a way to access any keymap other than the default.
Comment 11 Mohit Kheterpal 2014-01-13 07:25:09 UTC
*** Bug 17050 has been marked as a duplicate of this bug. ***
Comment 12 alex 2014-08-28 16:04:29 UTC
Would be great if someone can summarize what is the status of this bug. It's still being reproduced. I would be happy to have any solution that will allow me to press cmd+c/v/q/x at least to be able to copy/paste/quit XS with russian input.
Comment 13 alexey petrenko 2014-10-07 18:36:53 UTC
I can confirm that this is a very annoying bug and it is still 100% reproducible after two years.

The worst part is that shortcuts don't work even if you change the layout, YOU HAVE TO CLOSE THE XAMARIN STUDIO, CHANGE LAYOUT AND THEN START IT AGAIN! Any time! Just imagine how much time this consumes!

Why are you ignoring all these developers from outside the US? Is kind of rasism or what?))

Cmon, it should be easy to fix guys! :)
Comment 14 alexey petrenko 2014-10-07 18:38:07 UTC
JIC - my OS is Win 8, russian keyboard
Comment 15 alexey petrenko 2014-10-07 18:38:28 UTC
JIC - my OS is Win 8, russian keyboard
Comment 16 PaXLiCh 2014-10-08 07:27:22 UTC
As I know, it's a bug of whole gnome. For me no matter with what layout app was started. If first key was pressed not in US layout (even ctrl, shift), shortcuts will be breaked. Monodevelop is most crappy soft, crashes every minute, losing files and references, but price bigger than visual studio. Just buy Parallels Desktop + Windows 8.1 + Visual Studio 2013.
Comment 17 Alexey Kinev 2015-02-11 05:23:41 UTC
Confirm that bug too, I'm very surprised it lives for so long!

Mac OS X 10.10
Xamarin Studio 5.7.1
Russian keyboard

That's very strange to have such bug in native MacOS application, I'm not sure, but it seems like such mappings are done on OS level.

All shortcuts like Cmd-A / Cmd-C / Cmd-V / Cmd-Z etc are usually working in every application regardless of current layout, e.g. system receives Cmd-Ф / Cmd-С / Cmd-М / Cmd-Я on QWERTY/ЙЦУКЕН keyboard.
Comment 18 islandof 2015-02-14 22:01:00 UTC
Confirm the bug too,Use the global shortcut 'shift' switch  Chinese and English,It only not work in Xamarin Studio ,It work fine in Xcode
Comment 19 canab 2015-08-21 00:55:35 UTC
Three years people reported about inability of using keyboard shortcuts for editing texts (in IDE!). Sorry, but its a shame.
Comment 20 Cody Russell 2015-09-14 14:36:22 UTC
*** Bug 33645 has been marked as a duplicate of this bug. ***
Comment 21 canab 2016-01-05 10:44:07 UTC
Any progress on this issue?
IMHO ticket's status could be changed to CONFIRMED or even IN_PROGRESS :)
Comment 23 Andrey Verbin 2017-04-08 12:15:21 UTC
I have to say this issue is really annoying. Any chances to see fix anytime soon?
Comment 24 Cody Russell 2017-06-13 15:44:14 UTC
*** Bug 57123 has been marked as a duplicate of this bug. ***
Comment 25 FXD 2017-06-20 06:21:54 UTC
Is that bug hasn't fixed yet? This really annoying behaviour. REALLY. Please fix it as soon as it possible. It's too hard to work without cmd+c/cmd+v shortcuts. It doesn't work when we are using Russian keyboard layout.
Comment 26 Cody Russell 2017-07-01 19:54:31 UTC
I was trying to look into this issue again this week but I still don't have any good leads on a solution yet.

First of all, this isn't necessarily a bug on non-Latin keyboards. When I try to reproduce this in a Japanese input source I cannot - it works as expected in Japanese. It also works as expected in Russian when I'm on Linux, so I don't think it's a problem with GTK in general. It fails in Russian or Russian-PC on Mac.

What happens at the toolkit level is when the first key is received (or when the first key is received after the keyboard layout has changed) then we re-build our keymaps and cache the binding data in gtkkeyhash.c. The data for these keymaps ultimately comes from TISGetInputSourceProperty(TISCopyCurrentKeyboardInputSource(), kTISPropertyUnicodeKeyLayoutData). When I trace through that and add debug logging for MOD2 mask (which is our Cmd key) then in English and Japanese I'm seeing key mappings from keycodes 65 ('A') and 97 ('a') over to hardware keycode 0 (which is where the 'a' key is on my US keyboard).  When I look at this in Russian or Russian-PC the only keycode I see mapping over to keycode 0 is keycode 100 (which is 'd' and as far as I can tell isn't a key on these keyboard layouts).

I tried to search around and discovered that Qt seems to have the same issue and the bug is still open for them: https://bugreports.qt.io/browse/QTBUG-50865

These APIs that we're using to build the keymaps are Carbon APIs. I'll try to find out if there are some newer APIs that we should be using instead. It could be that Mac's Russian keymaps have changes that the Carbon APIs don't pick up or something.

If there is no newer API that we should be using, and if this really is just limited to Russian keyboard layouts, then perhaps we could have some hard-coded keymaps that get inserted (in addition to what the Carbon APIs return) specifically for Russian keyboard layouts. That seems kind of shady/hacky, but at the moment I have no leads to a better solution.
Comment 27 canab 2017-07-01 20:09:36 UTC
It is not only with Russian but also for other Cyrillic based layouts (at leas for Ukrainian)
Comment 28 alexey petrenko 2017-07-01 20:56:52 UTC
It is also not Mac-specific. I've reproduced this issue recently on Windows 8 and Windows 10 with Russian keyboard input.
Comment 29 alexey petrenko 2017-07-01 20:58:30 UTC
BTW, Cody Russell, thank you for looking into this. The problem is still really annoying after all those years. I am working around it by never using a Russian keyboard on the machine where I use Xamarin :)
Comment 30 alexey petrenko 2017-07-01 20:58:42 UTC
BTW, Cody Russell, thank you for looking into this. The problem is still really annoying after all those years. I am working around it by never using a Russian keyboard on the machine where I use Xamarin :)
Comment 31 FXD 2017-07-02 10:27:33 UTC
That ugly behaviour also appears in Visual Studio Community (MacOS).
Comment 32 Cody Russell 2017-07-28 16:32:39 UTC
*** Bug 45001 has been marked as a duplicate of this bug. ***
Comment 33 FXD 2017-08-17 19:39:41 UTC
No good news on that? :)
Comment 34 Cody Russell 2017-08-18 14:09:24 UTC
Oh, yeah sorry. This fix is committed. It should be available in the 15.4 release (15.3 is the current one.. I'm not sure exactly when 15.4 is)
Comment 35 alex 2017-08-18 14:10:39 UTC
15.4 now is alpha channel, maybe even in beta since recent stable release.
Comment 36 Cody Russell 2017-08-18 14:17:40 UTC
This fix may not be in the channel yet, but if you're on the 15.4 channel then next time it updates the Mono package you should get this fix.

Mono or later is what you want I believe.
Comment 37 gserg.g 2017-08-18 16:01:32 UTC
> 15.3 is the current one

Unless I'm being very thick, the current one on Windows is 15.1 (monodevelop-windows-d15-1) (both on XS and in VS), which also means we still cannot edit layouts for Android 4 (bug 56272). The Beta channel on Windows is empty, and there is 15.4 in the Alpha channel.
Comment 38 Matt Ward 2017-08-19 15:41:08 UTC
*** Bug 58904 has been marked as a duplicate of this bug. ***
Comment 39 Mohak Barokar 2017-08-22 12:53:35 UTC
Have verified this bug on “Visual Studio Enterprise 2017 for Mac (Preview) Version 7.2 Preview (7.2 build 547)” and it is found to be fixed.

Build Config:

-Visual Studio Enterprise 2017 for Mac (Preview) Version 7.2 Preview (7.2 build 547)

-Mono (2017-06/ebee14deca1) (64-bit)

-Xamarin.iOS Version:

-Xamarin.Android Version:
-Xamarin.Mac Version:

Detailed Build config: https://gist.github.com/mohakbarokar/befeba9293ee2ff0dda492e2025df481

Marking this Bug as verified/Fixed.