Bug 371877

I do not fully understand the problem. What exactly does not work as you expect. Could you please follow the steps to reproduce:

1. I did this
2. then I pressed this
3. then that

Actual Result: the following happened

Expected Result: but I wanted that to happen.

Fair enough.

1. I launched a Virtualbox VM (or other program that captures the local keyboard -- TeamViewer, Remmina, etc)

2. In the guest session, I pressed alt+tab (or any other alt+{key} or meta+{key} combo).

Actual result: my host changes windows

Expected result: but I wanted to change windows (or trigger some other shortcut) in the VM (or remote session, etc).

It's like KDE is being grabby with the key combos instead of properly passing it along to the app that's supposed to have captured the keyboard.

Sorry, but you also wrote about the "meta key" and menu opening? How is that related? So far your bug report is only about Alt+Tab which are normal global shortcuts? So how does the meta key play into that?

Same thing -- if I press the meta key by itself in the keyboard captured window, it launches the app launcher on the host _and_ the remote session / vm instead of only on the remote session / vm.

If I press a combo with meta {e.g. meta+D), my host shows the desktop, but the remote session / vm only receives a meta keypress -- not the whole shortcut.

I'm sorry if I'm being confusing -- this seems very straightforward to me.  Correct behavior was exhibited in KDE 5.7.5 that was bundled with Kubuntu 16.10.

I picked alt-tab as one example, but like I said in the original post, this appears to be true for any alt+{key} or meta+{key} combo.  Yes, they're global, but previous to installing KDE Neon, even global shortcuts were properly ignored by the host when an app was capturing the keyboard to send to a remote session / vm.

So these are two very different issues:
* global shortcuts
* meta shortct

The global shortcuts can only trigger if no other window has grabbed the keyboard. If they trigger on the host, the client has failed to grab the keyboard. This is a problem with the application. If a global shortcut is intercepted, the application does not get the key event. This is expected behavior.

Concerning meta: the modifier only shortcuts are triggered independently from the grab state of applications. That is whenever meta is pressed - without any other key, it will fire on the host system.

I'm not sure whether it would be a good idea to change that. It's a well defined state of the system now that pressing meta will open the launcher - no matter which application is open or what it does. I see both advantages and disadvantages there. There are multiple such keys already which cannot be send to the guest system. E.g. ctrl+alt+F1 cannot be send. Normally VMs provide solutions for that.

I _guess_ it's possible that virtualbox, teamviewer, and remmina all somehow 'broke' at the same time, but considering the exact same versions work fine under KDE 5.7.5 (and under Unity, Xfce, etc), I'm more inclined to believe something changed in KDE between 5.7.5 and present.

If you're saying that this new behavior is 'by design', then I guess KDE is not designed for sysadmins who need to support other OSs remotely.

> I'm running the latest install of KDE Neon (27/10/16), after upgrading from Kubuntu 16.10 (so KDE 5.7.5, I believe) which did not exhibit this issue.

Please not that this is an unsupported upgrade path! It might be that something broke badly.

> I _guess_ it's possible that virtualbox, teamviewer, and remmina all somehow 'broke' at the same time

You can easily test this. Use:
xdotool key XF86LogGrabInfo

That will print a section into /var/log/Xorg.0.log which will print which window currently holds the grab.

> If you're saying that this new behavior is 'by design', then I guess KDE is not designed for sysadmins who need to support other OSs remotely

If the opening of the menu on meta key is a problem to you, you can easily disable it for the time being. The other shortcuts should not fire when keyboard is grabbed. There is no change related to that at all. The global shortcut handling on X11 hasn't been changed for 12 months.

did you verify which application has a grab? That's rather important for knowing where to look for the issue

Thanks for being understanding.  My apologies for sounding like an entitled jerk.

It is a fresh install of KDE Neon -- I meant upgrade in the sense that I went from 5.7.5 in Kubuntu to 5.8.2 (now .3).  I ended up reinstalling again since the other Neon install was only a few days old, and I must have messed something up with the shortcuts in the original install.  Remmina and Virtualbox work mostly as you say, passing the combos through.  Virtualbox though sometimes misses alt+f4 and prompts to close the VM instead of letting the VM handle alt+f4.

TeamViewer is a mess, not capturing any alt or meta key combos.  I've raised a bug with their devs, who are calling it a 'feature request' (when it provides a checkbox to capture and send key combos to the remote host and doesn't do that, I call it a bug, but whatever...)

With respect to the key grabs, kglobalaccel5 has almost all of them -- I'm guessing each one is a specific combo and correlates to the global shortcuts?
kwin_x11 has another handful. I'm not sure if the focus has to be in Teamviewer or VB, but with both of them up and running (a VM loaded in VB and a remote connection in TV), the logs aren't reporting any grabs for them.

If the grabs only register when the focus is on the apps, should I set a cron job to run it and then leave the app focused?

To explain a little bit:

on X11 it's possible for a window to grab the keyboard. If a window does that all key events are sent to that window and not to others. So if e.g. Virtual Box has grabbed the key events, the global shortcut (like Alt+Tab) cannot be activated as kglobalacceld5 does not get the events.

If the global shortcut activates, it means the window has not grabbed the shortcut. And that's something you can verify with the grab tool.

Overall it sounds more like you have problems with those applications than with our software.

The same grab issue can be observed with QEMU.

Steps to reproduce:
1. Start qemu-system-x86_64 (no options needed, this will open the GTK GUI).
2. Click in the window, this will let QEMU grab the focus and change the title to
   "QEMU - Press Ctrl+Alt+G to release grab"
3. Press "Meta"

Actual results:
The Plasma kickoff menu opens.

Expected results:
The Plasma kickoff menu should not open.

I do not think it is useful to treat Meta specially to trigger an action given that all other shortcuts are disabled. Principle of least surprise is violated here.

For Ctrl-Alt-F1, Ctrl-Alt-Delete, etc., remoting software acknowledge that these complex shortcuts are interpreted by the host and QEMU/gvncviewer for example adds a menu option to send this keystroke. But the "Meta" key is not such a special key.

See also bug 371560 which requests the option to disable the "Meta" shortcut for Kickoff. (From a user's perspective, I also ran into the grab issue (this bug) and the linked Kickoff issue. Also, in all cases where Kickoff opened, I pressed Meta with the intent to press another key to trigger a shortcut, but then stopped. This got so annoying that I finally started looking for bug reports.)

@Thomas: I need an evaluation from usability perspective. Is it expected that the menu does not open on meta press if an application grabbed keyboard? Or should we consider the modifier only shortcut as bypassing everything.

From a technical perspective I might not be able to block the meta shortcut on X11, which would mean rollback to not providing the feature in case the conclusion is that grabs should prevent opening it.

If technically possible, modifier-only shortcuts should not bypass keyboard grabbing.
I would not consider them as equal to the likes of Ctrl-Alt-Fx. Those are "one level above" the desktop as they cen be used to switch away from it, whereas Meta for opening the start menu is a desktop feature.
Also, from a purely practical perspective, we don't want for example gamers to have to physically remove their meta key because they press it by accident all the time while playing shooters.

If it is not possible to prevent the meta key from triggering the menu opening even when an application grabs the keyboard on X11, however, I would not roll back the whole feature, under the assumption that removing the feature will have an impact on more people than not blocking it when the keyboard is grabbed.
As long as it is possible for users to manually disable it, that should be okay.

On X11 I don't see a possibility. The complete feature is built up on bypassing keyboard grabs. AFAIK we cannot get a notification if another window grabs the keyboard.

On Wayland we will have more control, though there is no support for applications grabbing the keyboard at all.

Adding a note from a remmina perspective:

Meta keys are used frequently when remoting into a Windows box:
<meta> by itself on windows provides same functionality as Kicker (user text search for applications and files)
<meta>+D minimizes all windows
<meta>+e file manager (Explorer)
<meta>+<arrow> splits window half screen in corresponding arrow direction.
<mete>+<pause/break> windows settings
etc.

Options:
1. Disable kicker meta shortcut entirely
2. Disable meta key with script when launching key capturing applications, re-enable when application is closed.  This is a pseudo solution, as kicker would not work while app is running.  I switch to local desktop frequently when remoted to a windows box. Though I use krunner to launch most of apps, I would have used the meta key long ago if it worked.  Thus, new users will expect it to work if switching from windows.
3. Provide a list of apps in a config file or possibly a "window rules" setting that will disable the kicker meta key when they have focus.  However, this requires the user to maintain the key grab setting in the app and in the config file.
4. Honor the key capture state of the application that has focus. Can the key capture state of an app be determined when the app obtains focus? If so, auto disable meta-kicker relationship when respective apps are set to capture the keyboard and re-enable when non-key capturing apps or local desktop has focus.


Option 4 is preferred as it requires the least amount of configuration.  Options 1, 2 and 3 keep KDE in the tinkerer's realm and discourages users who do not like to fiddle with their system.

Option 4 is not possible. We don't have any hints about that an application/window grabbed the keyboard.

Options 1-3 are all possible. For option 3 we do have a window rule which blocks global shortcuts and that also blocks the windows key triggering. We can also ship such rules by default, so that the user does not have to maintain them. But we will not be able to ship them to 5.8 users, that would have to go into Plasma 5.9.

I've run in to the same issue.
Option 3 seems most reasonable to me since option 4 cannot be done. Hopefully it won't be a lot of work to maintain that list.

Out of curiosity, does anyone know how Gnome (or maybe it's GTK) handles it? I just tried with both VirtualBox and VMWare, and it seems to be able to suppress the meta key on the host and send it only to the guest.

Hi there,

I can confirm this issue. When I use Synergy or Remmina and press the Meta key, the action is executed both on the KDE local host and the remote host.

For example: Synergy is active and mouse is moved to a Windows host. Then press meta key. The KDE menu AND the windows menu open at the same time.

This does not happen when I diable the modifier only shortcut in ~/.config/kwinrc by adding 

[ModifierOnlyShortcuts]
Meta=

and then using ksuperkey. This gives me back the correct behavior.

Hope this helps :)

On Wayland there is now a protocol for shortcut inhibitions. I plan to implement this for 5.12. This would improve the situation on Wayland.

For X11 I can only recommend to use the block global shortcut window rule.

This issue is one of the only major usability problems I have with KDE, so I thought I might chime in. I see this issue when using virt-manager, the libvirt GUI tool, and synergy, a software keyboard & mouse switch.

In virt-manager, if I create, run, and log into a KDE VM, my keypresses get captured by the VM as expected. However, if I hit Meta, the Application Launcher opens on both the host machine and the VM. If I hit Alt+F1, only the Application Launcher in the VM opens, as expected.

The same thing happens in Synergy. If I am running a Synergy server on one KDE machine, and then run a Synergy client on another KDE machine, I can set it up so that moving my mouse to the side of one screen makes the cursor show up on the other machine's desktop, at which point my mouse and keyboard control gets passed to the Synergy client as expected. However, hitting Meta opens the Application Launcher on both the host and client, unexpectedly. Hitting Alt+F1 behaves correctly.

(In reply to Martin Flöser from comment #20)
> On Wayland there is now a protocol for shortcut inhibitions. I plan to
> implement this for 5.12. This would improve the situation on Wayland.
> 
> For X11 I can only recommend to use the block global shortcut window rule.

This is still a problem as of Plasma 5.16.x. The Wayland protocol implementation would be fabulous. It is implemented in GNOME's Mutter.

How difficult is implementing this would you say? Maybe it could be a Google Summer of Code project.

support for keyboard_shortcuts_inhibit has been added in the meantime