search

TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
747 stars 137 forks source link

Ctrl + Shift + Alt + Arrows are blocked by TurboVNC viewer #348

Closed Patrick-Poitras closed 1 year ago

Patrick-Poitras commented 1 year ago

Hello all,

I upgraded TurboVNC client 2.2.7 to 3.0 in the last week, and as a consequence, I can no longer use Ctrl+Shift+Alt+<Arrow keys> to perform selection inside emacs. I have confirmed that this bug is in TurboVNC3 by connecting both client versions to the same target at the same time. The behavior is reproducible in my current use case.

I tried troubleshooting by changing options, to no avail. No setting of keyboard capture seems to change anything. The rest of the options have been tried a handful at a time without improvement.

The "About" page in version 3 (not working) states:

TurboVNC Viewer v3.0 (20220503)
[JVM: OpenJDK 64-Bit Server VM 11.0.15 amd64]
Built on 2022-05-03 at 13:12:32

The about page on version 2.2.7 states

TurboVNC Viewer v2.2.7 (20211221)
Build on Dec 21 2021 at 21:18:52

All are running on Windows 10, and targeting Linux containers Please let me know if I can provide any further information that might be helpful. Thanks!

dcommander commented 1 year ago

Are those standard documented hotkeys in Emacs, as opposed to custom hotkeys that you configured?

The TurboVNC Viewer typically uses Ctrl-Alt-Shift hotkey combinations for various things, because I thought (apparently incorrectly) that those modifiers wouldn't be taken by other software. The Java TurboVNC Viewer has traditionally used Ctrl-Alt-Shift- to move the scrollbars, if scrollbars are visible on the viewer window. So what you're observing is likely a result of the transition from the Windows native TurboVNC Viewer in TurboVNC 2.2.x and prior to the Java TurboVNC Viewer (with an embedded/bundled JRE) in TurboVNC 3.0.

Possible solutions:

  1. The TurboVNC Viewer could disable those hotkeys if scrollbars aren't visible. (This is definitely the cleanest and easiest solution from my point of view. It would mean that Emacs users could use those hotkeys as long as they are using screen scaling or automatic desktop resizing in a way that prevents scrollbars from appearing.) This would make sense irrespective of any other solution.
  2. The TurboVNC Viewer could allow the modifier combination for hotkeys to be selectable via a command-line parameter and/or environment variable.
  3. The TurboVNC Viewer could pass through those hotkeys if keyboard grabbing is enabled, as it does with Alt-Tab. That would make a certain amount of sense, since moving the scrollbars via hotkey is a similar type of operation to switching windows via hotkey.
Patrick-Poitras commented 1 year ago

Thanks for the quick and detailed reply!

For emacs, it is a default keybind. I confirmed it using a session spawned with emacs -Q which disables all customizations. Ctrl-Alt-Left and Ctrl-Alt-Right move the cursor to the start or the end of an s-expression, respectively. The Shift-Ctrl-Alt version does the same thing with selection, much like Shift-Ctrl-Left selects a word.

All three solutions sound like they would solve the issue. If my input can be of any help, my preference from a user standpoint would be 1 and 3, as those seem to fit nicely within the VNC workflow. For the third one, I did try that to see if it worked as part of the troubleshooting process, so with a sample size of N=1, I'd say that discoverability for the feature should be pretty good. Despite this, my preference would be for solution 1, but I'd be happy with any of them.

Cheers!

dcommander commented 1 year ago

I'll make sure that those fixes are in the upcoming 3.0.2 release.

dcommander commented 1 year ago

NOTE: GNOME seems to also override those hotkeys, using them for desktop switching, which is all the more reason that they should be transmitted when keyboard grabbing is enabled.

dcommander commented 1 year ago

Should be fixed now, and pre-release builds containing the fix will be available shortly. Please test.

Patrick-Poitras commented 1 year ago

Thank you, will report back once they become available. Cheers!

dcommander commented 1 year ago

They're available now. It only takes 10 minutes after the commit for the builds to spin.

dcommander commented 1 year ago

https://turbovnc.org/DeveloperInfo/PreReleases

Patrick-Poitras commented 1 year ago

It works! \😃/

Thanks for the help!

Patrick-Poitras commented 1 year ago

@dcommander I'm now having a slightly different problem, where if I press the Alt key, and don't press anything else and release, it shifts the focus away from the window, and then if I press keys, there's a window that pops up. image

It does this even if there's keyboard grabbing, which makes it a mess. The key sequence that reproduces this 100% of the time is roughly "Alt_Down Alt_Up Up_Arrow_Down" I don't know if it has anything to do with the new patch, but I assume it's close enough to not make a new ticket.

I have tested version 2.2.7, and it doesn't have the same issue. I will try installing 3.0 to compare with the development version and report back.

Edit: The non-development version also has this problem. I'll open a new ticket on Monday, once the turkey festival is over.

dcommander commented 1 year ago

Argh. This appears to be some sort of "feature" of Windows. I've tried the following workarounds, to no avail:

I haven't given up on it yet, but unfortunately I need to release 3.0.2, so this will have to wait until 3.0.3.

dcommander commented 1 year ago

@Patrick-Poitras Note that the Alt behavior described above is unrelated to this issue (Ctrl-Shift-Alt-arrow keys), so for tracking purposes, it would be better to file that as a separate GitHub issue.