How can you reproduce this issue (i.e. how can you see this behavior on the remote desktop)?

I'm getting the same issues with KDE 4.4-rc1. Window switching keys are not taken by krdc. i.e.:
- Alt+F4
- Alt+Tab

Instead of closing a window within the session, the whole session window is closed.

Sorry for not replying for such a long time. The issue still exists, though.

@ #2: have you tried to enable the option "grab all possible keys"? For me, your issue does not exist with that option.

With the option disabled, however, I can leave the remote session via Alt-Tab (which is expected behaviour, imho), but as stated in my first comment, I have the problem with the alt-key.

I get this problem e.g. when working via vnc on another linux box (didn't try rdesktop and windows). In the remote session a window is active, say Matlab. When leaving krdc via alt-tab and returning via alt-tab, the Matlab-Menu is active, and everything I type is handled as if the alt key was pressed. When I press e.g. "f", the file menu is opened. To "release" the alt key in the remote session I have to press the alt key once on my keyboard.

The issue does not occur when leaving krdc with the mouse via the taskbar, and returning via alt-tab.

This bugs still exists. Ubuntu 10.04 64-bit with Gnome+Kde installed and working from Gnome desktop.

KRDC using RDP plugin.

KRDC with grab-all-possible-keys enabled on windowed/tabbed mode works just fine but on fullscreeen mode, even with grab-all-possible-keys enabled does not get the ALT-TAB event. In fact Gnome get this event and the window (KRDC) context get lost. Solution: exit fullscreen mode and re-enter it and not even thinking about using ALT-TAB on fullscreeen mode...

Come-on guys, this bug makes KRDC unusable to work with :(

Raine

(In reply to comment #4)

What does happen if you are running rdesktop from Konsole? Does also the desktop (= window manager) get these key events?

I can confirm that bug, using opensuse 11.2/11.3 with krdc-4.4.4.

rdesktop in full-screen mode started from shell does't show that behavior.

Yes, it's really an annoying feature... :-(

This bug also exists on Debian GNU/Linux Squeeze. Or at least I suppose so.

Experienced behaviour:

I use KRDC to connect to Mac Mini's running Apple's native VNC server, a.k.a. 'Screen sharing'. After switching away from KRDC with 'ALT + TAB', and then back again, the keyboard input in the VNC session is really messed up. I get two caracters per keypress, and other wierd behaviour. Pressing the ALT key again sometimes fixes things. Sometimes I get different behviour in the different programs in the Mac Mini session.

+1 for annoying bug

*** This bug has been confirmed by popular vote. ***

Hi, I believe this is the bug in rdesktop and not krdc. Rdesktop checks and clears state of meta-keys only when receiving FocusIn event. It works fine when rdesktop is run as standalone application, but not when embedded in krdc. I filled bug (with proposed patch) to rdesktop: http://sourceforge.net/p/rdesktop/bugs/363/

Can you reproduce with KDE SC 4.14.1 and freerdp? This seems a duplicate (at least partially) or bug 178015.

I can reproduce this every time with krdc 4.14.1 and freerdp, but if and only if I go back to krdc using the mouse. If I use the keyboard, the Alt is considered released.

In other words, there is no problems if I leave and enter symmetrically - both using the keyboard or both using the mouse. It only happens if using the keyboard to leave and the mouse to go back.

This also happens with Ctrl.

For example, this will show due to a conflict between VMware vSphere's pseudo-Ctrl+Alt+Del, Ctrl+Alt+Ins, and KDE's Ctrl+Alt+Ins (which, as I discovered due to this conflict, allows switching session). If one uses a remote vSphere console and tries to send Ctrl+Alt+Del to a remote host, the local KDE with catch the Ctrl+Alt+Ins and offer switching sessions. If one cancels that using Escape, the focus goes back to krdc, but Ctrl and Alt stick, even if they were released. This will likely cause the session to disconnect, since the next press on Enter may be interpreted as Ctrl+Alt+Enter, which causes krdc to disconnect.

This is a major annoyance for vSphere usage. There are workarounds:
Send the shortcut graphically (VM->Host-> Send Ctrl+Alt+Del)
If you forget and trigger KDE's shortcut, type Ctrl and Alt
Unfortunately, if KDE's shortcut can be controlled, I did not find where.

It is interesting to note that it's not just the remote session where Ctrl+Alt stick - Ctrl+Alt+Enter is a krdc shortcut, meaning krdc itself has Ctrl+Alt stuck.

This is still a problem. I like krdc (over gvncviewer) exactly because it switches desktops and windows of the main system on Alt-Tab and Alt- other keys.

There's still a problem with locked Alt key when I switch the krdc window to another window. The problem is, in particular, when I switch back and the whole desktop inside behaves as if the Alt key were pressed, even if it's actually not pressed (which changes the behavior of any key combination).

So I propose a solution: please make krdc on the event of "lose focus" (which may be a result of Alt-Tab), send the Key Release (or whatever it's called) events for Alt - as I can see above, probably the same can be required for Control, Shift and Meta. To prevent unnecessary flooding, it can simply record Key Press and Key Release events to update the modifier key state, and on Lose Focus event send Release events only to the keys that were remembered as currently Pressed.

If this can make things bad for anyone, you can make it an option - but really it shouldn't be harmful, as it's hard to imagine a situation when the window is NOT focused and any key is pressed.

bump!

this is still a problem (IMO the most annoying bug in KRDC) in 2018 (using current Neon).

If I find the time, I'll try to fix this myself next week or so. But since I don't know the source (yet), any hints on where to start and what problems this might cause are welcome.

Also... is this a bug in krdc at all, or is it maybe an issue in xfreerdp?

I tried to fix it but pretty much hit a wall with plugin loading.

this might be slightly off topic for a bug report, but...

when i try to debug krdc (per gdb or qCDebug) this only works for parts of it.
The problem is that the plugins (libkrdc_rdpplugin.so in this case) or always loaded from the system-installed krdc.
Of course I could to something like link from there to my compiled plugins, but I'd prefer not to pollute my system...

So... @developers: how do you set everything up for KRDC development?

If you want an application to work outside of the standard /usr prefix, you need to set environment variables to point to the installed files. These are documented at https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Set_up_the_runtime_environment

With recent extra-cmake-modules versions, it is also possible to automate this, see http://www.proli.net/2018/06/29/easily-building-and-testing-kde-applications-into-a-separate-prefix/

Ok... so i looked at the code, played around and realized 2 things:

The bad:
I don't think this problem can be fixed in krdc alone. 
The solution Sektor van Skijlen proposed is how I'd try to solve it - but this can't be done because embedding another X application blocks most focus events from krdc.
Possible workarounds: 
  a) having kwin (or a kwinscript) notify krdc if the window changes via dbus.
     Contra: would depend on using a window manager that can do that - AFAIK this means kwin or xmonad.
  b) Monitoring xfreerdp for messages that hint at a focus change.
     Contra: might need modifiyng freerdp.
  c) Fixing whatever causes the lost focus events (possibly Qt - more likely X. And there is no way I'm touching Xorg code!)

Has anyone tested this on wayland? if so: whats the situation there?

The good:
the above isn't really necessary, as freerdp has already (mostly) fixed this :)
In my tests with the current version from git (2.0.0-dev4) keys are almost always properly released. Beeing a development version, of course, it has some quirks (like sometimes randomly grabbing all keys until you press right ctrl). But I found using it more pleasant than having to deal with unreleased keys.

In short: workaround = upgrade to current freerdp from git.

If anyone really can't use the git version I might be persuaded to implement a). Otherwise I'll consider it "almost resolved upstream". (is this enough to change status to resolved ?)

also: @Christoph Feck thanks for the links :). However this wasn't enough, as krdc would still load both versions of the plugin - and always use the wrong one :/.
I worked around it by placing these 2 lines at the start of MainWindow::loadAllPlugins()
    const QString badpath = QString::fromUtf8("/usr/lib/x86_64-linux-gnu/qt5/plugins");
    QCoreApplication::removeLibraryPath(badpath);

Hi @Alex,

I am using 2.0.0-dev5 and still experiencing that issue

elias@ecdl15:~$ xfreerdp --version
This is FreeRDP version 2.0.0-dev5 (2693389a+debian)

Any suggestions ?

I still have this (really annoying) problem with KRDC 19.12.3 and xfreerdp 2.2.0 on Kubuntu 20.04.

The best workaround I could find is to disable global shortcuts for KRDC application, so that Alt+Tab goes to the remote system rather than being captured by Plasma. This has other advantages, but still the "out-of-the-box" experience is much affected by this problem.

Just got a notification about this bug, I'm really surprised that it's still running around.

Of course this can be fixed very easily, I thought I hinted that already:

If any of the modifiers key has been sent to the application (or you can get virtually any key), the state of keypressed should be remembered. When the Key Release event is coming to the application, this state is cancelled. When the window loses focus, and there is any KeyPress event earlier recorded (and not cancelled by KeyRelease), you send the artificial KeyRelease event of the same key.

I guess this problem might touch upon more applications than KRDC, but in KRDC it's most visible and annoying. Although normally applications take care of that problem some easy way (for example, by executing events only on KeyRelease event), in KRDC the situation is special because the key event is sent to the underlying desktop, and the KeyPress event is recorded, but with no other key being released at the same time, it interprets it as pressed single Alt key.

This sounds like it might be fixed by the fix for BUG 484992 (https://invent.kde.org/plasma/kwin/-/commit/8fd4476ff1848ce7ce4d3573224fc4893ae8339d). Would anyone be able to confirm if that is correct? Thanks!

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

(In reply to fanzhuyifan from comment #21)
> This sounds like it might be fixed by the fix for BUG 484992
> (https://invent.kde.org/plasma/kwin/-/commit/
> 8fd4476ff1848ce7ce4d3573224fc4893ae8339d). Would anyone be able to confirm
> if that is correct? Thanks!

My task switching shortcut is now Meta+.  (where '.' would be 'e' on a qwerty based layout). When using this, the windows start menu opens on the remote machine, so it's still not fixed.

Unless maybe that fix is not yet merged in the version I'm trying to use (24.08.0)...

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.