On a Windows 10 box, I found that I can't send Shift+Tab to (at least some) applications, such as Notepad++.

I am using that machine remotely via a VNC session (Remmina client under Xubuntu, the Windows machine is running TightVNC server) and my original thought was that the shortcut gets processed by the VNC client or the local OS, but testing the same with a remote Xubuntu machine does send Shift+Tab through; e.g. I could unindent a line in Mousepad which is Xubuntu's default text editor.

Is there a Windows 10 setting or shortcut causing Shift+Tab to be directed away from Notepad++?

Any information on how I could debug this issue would also be appreciated.

  • 1
    Another question: What about other shortcuts such as shift+ctl+tab, alt+tab, etc. Are they working? – Woeitg May 12 at 6:57
  • 1
    What about Backspace, or Shift-Backspace? – Didier May 12 at 6:59
  • 1
    I suspect all shortcuts with "shift" in it does not work. You may try yourself all different shortcuts and see if it is true: code2care.org/pages/… – Woeitg May 12 at 7:13
  • 1
    you may also try to use OSK to simulate shift +tab and see if it works – Woeitg May 12 at 7:34
  • 1
    Try to press the key in Remmina Preferences > Keyboard tab > Grab keyboard, just before the shift+tab. See also if this answer is relevant. – harrymc May 12 at 10:24

The solution below fixed the problem for the user. The problem is that basically the combination of Shift+Tab is not unique and may be mistaken when transmitted to the server. This problem may occur when using VNC between non-Linux and Linux computers.

This same problem is evoked in the post using Alt-Gr from a Windows VNC client to vino. Although dating from 2007, the answer by Dan Winship still applies:

the problem is that the server side (the machine running vino) considers the Tab key to have two different keysyms on it (Tab and ISO_Left_Tab respectively), whereas the client side considers it to only have one keysym on it, and so expects Shift+Tab to be treated the same way as Shift+Up Arrow.

(I assume the client is a non-Linux box?)

I don't think there's a "clean" fix for this; the client and server are both behaving reasonably, this is just one of those warts in the protocol. The only way to fix it would be to special-case the Tab key in the code. If you want to suggest doing that, you should probably file a new bug (and refer to the comments in this one).

You can work around the bug by running

xmodmap -e 'keycode 23 = Tab'

(on the vino box). This doesn't seem to interfere with ordinary gtk operation, so it's probably safe to do this all the time. (Eg, putting 'keycode 23 = Tab' into ~/.xmodmap or ~/.Xmodmap or something might cause it to automatically be evaluated, depending on your distro)

In the more recent post Shift + special key does not work using real vnc viewer in windows to access ubuntu where the same method was used to fix the problem:

Run in Ubuntu terminal: xmodmap -e 'keycode 23 = Tab'

EDIT: to make the fix permanent run sudo vim /usr/share/X11/xkb/symbols/pc and change the line

key <TAB> { [ Tab, ISO_Left_Tab ] };


key <TAB> { [ Tab ] };

After that reboot.

| improve this answer | |
  • Thanks for your answer. While the xmodmap -e 'keycode 23 = Tab' command seems to have worked, trying to make it permanent via editing /usr/share/X11/xkb/symbols/pc didn't: I got the no keyboard is found problem at the login screen. Note that I have only tried to comment the original line with // and add the new key line, so syntax errors could be an issue there... I'll need to backup the file and edit the line in-place to see if this will work. Note to self: I had to fix the login via GRUB recovery. – FriendFX May 15 at 5:47
  • It works without the comment line, just delete the part , ISO_Left_Tab from the key <TAB> line. – FriendFX May 19 at 0:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.