Right-click context menu disactivates the very hotkeys (keyboard shortcuts) it shows

Version: (using KDE KDE 3.1.94)
Compiler: gcc (GCC) 3.3.2 20031022 (Gentoo Linux 3.3.2-r3, propolice)
OS: Linux

When a combo box (or drop-down list, or whatever) is active, none of the KDE shortcuts work (at least, I haven't found a shortcut that _does_ work, so I'm assuming that none work).

Not simple to fix, if it's possible at all.

*** Bug 73730 has been marked as a duplicate of this bug. ***

Very annoying when you start typing URL and realise that you need to change your keyboard layout (Ctrl+Alt+K)

*** Bug 63141 has been marked as a duplicate of this bug. ***

Really annoying behavior, any clues of what might be causing it?

Because it calls XGrabKeyboard, IIRC; this is most likely to prevent some sort of races/confusion, but I am not sure

*** Bug 78761 has been marked as a duplicate of this bug. ***

*** Bug 86557 has been marked as a duplicate of this bug. ***

*** Bug 86864 has been marked as a duplicate of this bug. ***

*** Bug 53315 has been marked as a duplicate of this bug. ***

*** Bug 93571 has been marked as a duplicate of this bug. ***

*** Bug 97733 has been marked as a duplicate of this bug. ***

*** Bug 107696 has been marked as a duplicate of this bug. ***

this is annoying me, too.

I often switch between english and german on an english keyboard layout, especially in apps like konqueror.

So my keyboard shortcut is kind of hard-coded into my typing.

often when I find I need or don't need anymore umlauts typing a url like gg:füsch or http://... I

  get the wrong character
  backspace
  keyboard switch (fails because of this bug)
  get the wrong character again
  backspace again
  escape to get rid of the completions
  keyborad switch again
  get the right character

I understand it's not the highest on the list but it's annoying.

thx

*** Bug 123657 has been marked as a duplicate of this bug. ***

*** Bug 123840 has been marked as a duplicate of this bug. ***

Version: (using KDE KDE 3.4.3)
Installed from: Ubuntu Packages

On KDE Desktop and in Konqueror:
1. Open a context menu by right-clicking on a file.
2. See in the context menu "Rename F2".
3. Press F2.

Result - No response.

There is no reason that the keyboard shortcuts should stop functioning if a context menu is open.

This behavior is still present in KDE 3.5.3 ...

I checked this now also with non KDE applications, and I see the same behaviour there (in Menus). Even on Windows this is the same.
Interestingly, in QT4 (designer) it works as you like to have it ...

The same bahaviour also occurs whenever a menu, any menu, including the K menu and applications menus is open. Not to be outdoneby Susanne (#14), an example of when this is irritating is this:

1. Browse K menu to find an application.
2. Realise that this application might play sound and I don't want that right now.
3. Try pressing the volume control or mute buttons.
4. It does not work. Close menu, adjust volume, navigate menu again.

Bug 123657 informs us that the same thing happens for right-click menus. Bug 107696 notes that it applies when passive windows pop up; "say for example autocomplete/intellisense in KDevelop".

So we have:
1) Combo boxes and friends (e.g. address field in Konqueror, autocomplete/form field suggestions on web pages)
2) Menus: application menus, RMB menus, K menu
3) (anything else?)

*** Bug 148465 has been marked as a duplicate of this bug. ***

*** Bug 143766 has been marked as a duplicate of this bug. ***

*** Bug 147419 has been marked as a duplicate of this bug. ***

After investigating problem, it seems this problem also occurs with Qt only
applications, and still occurs with Qt 4.3(with qt-copy patches) as well as
Qt 3.3. When trying to narrow down to what call grabbed the keyboard, I also
discovered that when the window with the popup does not have focus, shortcuts
will still work.

Tested on KDE 3.5.7 with volume controls/Xmodmap and a svn checkout of qt-copy
from KDE for Qt 4.3.

*** Bug 151573 has been marked as a duplicate of this bug. ***

*** Bug 139543 has been marked as a duplicate of this bug. ***

*** Bug 152511 has been marked as a duplicate of this bug. ***

In KDE4 kxkb allows to use XKB shortcuts to switch keyboard layout, and if you use those popup windows won't stand in a way. So at least for layout switching (which I understand is most of the cases) we have a workaround.

Lubos/David, what is the status of this bug/patch? Has there been an attempt to get this into Qt? It is an upstream problem, so it doesn't belong here.

Feel free to try to push the patch upstream.

the loop in the second hunk can be made less arcane:

while (QWidget *popup = qApp->activePopupWidget())
    popup->close();

i can't comment on the patch in detail, but it seems plausible, so feel free to submit upstream for discussion. lubos, note that you need to do that yourself for legal reasons.

I can write my experience:
if I open KDE menu, and press the laptop's keyboard shortcuts to manage brightness, they will not work.

Dan Duris: This is not about priorities. This is about grabbing keyboard events completely so that they are no longer received by any X client other than the popup owner - including window manager (kwin) and any other component of KDE.

This patch is of course an improvement of Qt library, but it will not SOLVE this issue.
Solution will be partial: popups created by Qt applications will stop blocking global shortcuts, but popups from GTK based applications won't.
This will cause the user experience to be incoherent.

And duplicates of this bug will continue to appear, because users do not care/understand why this will not work in GTK applications.

GTK has to fix this as well in the same way. But I wouldn't count on its developers.

> This will cause the user experience to be incoherent.
>

Not incoherent, but maybe inconsistent. However, many (most) other KDE bugs that cause inconsistency between Qt and GTK are handled by doing the right thing in Qt and ignoring whatever GTK does. Therefore the fact that GTK apps will still have the problematic popup is not a reason to not fix this issue in Qt apps.

(In reply to comment #64, #71, #72)
> [what about GTK?]
Is this a problem with gtk based apps at all??

FWIW, this looks now fixed for me: I'm currently running KDE 4.7.2 from KDE:KDE4:STABLE:Desktop on an openSUSE 11.3.

With pop-ups open, global shortcuts work for me in both gtk and qt based applications (firefox, google-chrome for gtk, konqueror for qt 4.7.4).

Dotan Cohen:

Yes, inconsistent was what I meant.

> Therefore the fact that GTK apps will still
> have the problematic popup is not a reason
> to not fix this issue in Qt apps.

Not at all. I'm totally for this improvement in Qt.

I'm just saying it will not fix the problem everywhere, unless this change is implemented in every toolkit.
Or the fix is done somewhere else where it will affect all the applications, ex. in x11lib. But I guess they will not agree to modify grabbing system just because toolkits handle it wrong.

Susanne Oberhauser:

Are you sure you have tested it with popups like *context menus* or *main menus*?
Popup windows (ex. JavaScript alert() in web browsers) are not popups in this context, because they do not grab mouse and/or keyboard.

(In reply to comment #74)
> Susanne Oberhauser:
>
> Are you sure you have tested it with popups like *context menus* or *main
> menus*?
> Popup windows (ex. JavaScript alert() in web browsers) are not popups in this
> context, because they do not grab mouse and/or keyboard.

I originally had the issue with the URL in konqueror. I typed "gg:süß", the history starting "gg:" popped up, I saw gg:s[-, and I realized I need to switch keyboard and then the shortcut didn't cut it :)

as per now, in all three brosers (konqeror, firefox, chrome) the shortcuts work with the pop up open. the same works for the main menu in chrome and the file menu in kmail2.

(In reply to comment #75)
> I originally had the issue with the URL in konqueror. I typed "gg:süß", the
> history starting "gg:" popped up, I saw gg:s[-, and I realized I need to switch
> keyboard and then the shortcut didn't cut it :)
>
> as per now, in all three brosers (konqeror, firefox, chrome) the shortcuts work
> with the pop up open. the same works for the main menu in chrome and the file
> menu in kmail2.
See comment #27. Switching keyboard layouts does work (the main shortcut for this is handled directly by xkb), but the global kde shortcuts do not... and that's what this bug is about.

*** Bug 298021 has been marked as a duplicate of this bug. ***

*** Bug 320937 has been marked as a duplicate of this bug. ***

FYI: ksnapshot 4.10.3-1.30.1 will not capture a screen view if there is a menu pulled down in the Thunderbird 17.0.6 configuration page (specifically, the list of authentication methods).
KDE 4.10 openSuse 12.3 libqt 4.2.4

Posted here because a more specific bug was marked as a duplicate of this one.

*** Bug 328463 has been marked as a duplicate of this bug. ***

*** Bug 335333 has been marked as a duplicate of this bug. ***

*** Bug 349802 has been marked as a duplicate of this bug. ***

Good news: Plasma 5.4 will come with a new experimental Wayland backend. With Wayland we are able to better handle this situation and this issue should already be fixed in 5.4 on top of Wayland.

Given that it is an issue with X11 and unfixable with X11 I dare to mark the bug as resolved.

Thank you for these good news Martin, but users will not stop using X11 because this doesn't affect it.
That Wayland is not affected does not resolve the bug.

Unless this is not considered a KDE bug (in which case this should be marked INVALID), this should be retitled to specify X11 specificity and reopened until it is fixed in KDE, or until KDE drops support for X11.

Thanks Filipus Klutiero,, agreed.
Looking at the votes, this is no minor bug.

I'm sorry but this bug is not fixable with X11. It's a design problem in the X11 protocol and thus cannot be fixed on X11. It's pointless to keep the bug open for X11 as it cannot be fixed. Also there is no other place to report the bug and get it fixed. As it's a design problem in the X11 protocol it can only be fixed by a different protocol - e.g. Wayland.

As this happened now and we have support for it, I consider this bug as fixed. Please note that in KDE bugtracker we mark bugs as resolved fixed as soon as there is code which fixes the bug, not when it reaches the users. This might be unfortunate for the user, but it's the only way how we developers can handle our bugs.

This is certainly fixable with X11. Even if it was not going to be fixed, there would be a point in keeping the ticket open, i.e. allowing users to find it.

Indeed, tickets are marked as resolved when there is code which fixes, not when we find a context where "the bug does not appear".

> Given that it is an issue with X11 and unfixable with X11 I dare to mark the bug
> as resolved.

Though I agree with the RESOLVED status if KDE devs have no intention of working on this, I disagree with the RESOLVED FIXED status unless KDE has Wayland as an official dependency. Perhaps RESOLVED WONTFIX would be more appropriate?

I say this with complete respect for the KDE devs and their time. I have nothing but appreciation for you guys!

> This is certainly fixable with X11

No, it's not. The problem is that a popup window normally grabs the keyboard and while the keyboard is grabbed no other process is able to get key events. The result is global shortcuts cannot work. As long as the X11 protocol allows to grab the keyboard and as long as there is no global shortcut support directly integrated into the X11 protocol this is unfixable. For both we need a new protocol - we can call it X12 or Wayland, doesn't matter.

> I disagree with the RESOLVED FIXED status unless KDE has Wayland as an official dependency

Wayland has been a hard dependency of the Plasma workspace since the 5.2 release. Wayland is used already every time you lock the screen.

So let's not discuss semantics. I as the developer working on this issue decided that it's fixed and let's please stop the discussion about that. It just takes my time away from working on Wayland support :-)

> Wayland has been a hard dependency of the Plasma workspace since
> the 5.2 release. Wayland is used already every time you lock the screen.

I did not know that. If that is the case, then the issue is closed!

> So let's not discuss semantics. I as the developer working on this issue decided
> that it's fixed and let's please stop the discussion about that. It just takes my time
> away from working on Wayland support :-)

Thank you Martin. As always, your valuable time is appreciated! Have a terrific week!

Martin,
It may remain forever the case that global shortcuts don't work when any popup is active in X11. But that stops being a bug when users stop being deceived, for example thanks to documentation.

I do not consider you or anyone as "the developer working on this issue", but in any case, nobody decides that bugs are fixed. Anybody can fix bugs, or not.
No one has asked you to participate or even monitor this discussion. All you were asked is to leave the ticket open until the issue is solved, just like we ask anyone to do with any ticket.

@Filipus: You might notice that Martin is a KDE developer, is working on this issue, and furthermore he is the _only_ KDE developer that is working on this issue. Thus, he is "the developer working on this issue".

You are correct in the sense that anybody is welcome to contribute code for consideration to be included in KDE, thus if you would prefer that somebody else become "the developer working on this issue" then please convince them, or yourself, to do so. Until then, Martin remains "the developer working on this issue". As in free software as in love, badgering or insulting somebody until they do what you want will not work.

Do whatever you want to do with this bug report, I'm out of here!

Dotan, I do not think of someone who considers an issue solved as working on that issue. And if the solution is deprecating X11, this will involve more than a single developer. Besides, as I wrote, bugs are not fixed because people decide they are - they are fixed when the software is changed.

This is a well-known limitation of the X protocol, as explained by both experts Lubos Lunak and Martin Gräßlin. Further discussion of this seems to be pointless now that Wayland is going to replace it.

Maybe I'm not an expert, but If its a limitation of X protocol, then why bug doesn't occur in firefox? It also work under X....
Let me explain. When you activate popup (try right button menu) and then try any shortcut. In firefox popup will be simply closed and shortcut will be executed. This is the behaviour I would expect and if its possible in firefox it should be possible in KDE.

@bartek

You are right, it works for Firefox. But not for apps created with Qt4, GTK2 and GTK3.

The reason is Firefox (XUL?) grabs only the mouse pointer and not the keyboard when displaying a context menu. While the rest of the above grab both mouse and keyboard, thus overriding separate keyboard grabs for the shortcuts.

So, to fix this issue we would need to modify Qt (maybe already fixed in Qt5?) and GTK not to unnecessarily (?) grab the keyboard when displaying menus.

Please find the 'grabtest' program in the attachment. It checks whether mouse and/or keyboard are already grabbed.
Comilation: gcc -lX11 grabtest.c -o grabtest
Test: Run "sleep 3 && ./grabtest" and quickly open a context menu

Results:
1) no context menu:
MOUSE GRAB SUCCEEDED
KEYBOARD GRAB SUCCEEDED
2) Firefox context menu:
MOUSE GRAB FAILED, already grabbed?
KEYBOARD GRAB SUCCEEDED
3) Qt4 context menu (tested with Konsole 4.14.2)
MOUSE GRAB FAILED, already grabbed?
KEYBOARD GRAB FAILED, already grabbed?
4) GTK2 context menu (tested with GIMP 2.8)
MOUSE GRAB FAILED, already grabbed?
KEYBOARD GRAB FAILED, already grabbed?
5) GTK3 context menu (tested with Cheese 3.14.1)
MOUSE GRAB FAILED, already grabbed?
KEYBOARD GRAB FAILED, already grabbed?

Created attachment 95476
grabtest.c

So, as <email address hidden> said, maybe the Wayland will fix this.
I just hope they have people who think about all the possible use-cases or leave wide space for extensions before creating the protocol...
(sorry for my ignorance, I didn't check the Wayland protocol yet)

ultr> You are right, it works for Firefox. But not for apps created with Qt4, GTK2 and GTK3.

Funny. On my Debian GNU/Linux Jessie this problem does *not* occur in Qt4 programs (including KDE software). While GTK- (v2 and v3, except of Mozilla’s software) and Tk-based interfaces are affected.

$ konqueror --version
Qt: 4.8.6
KDE Development Platform: 4.14.2
Konqueror: 4.14.2

However, it’s quite possible that I just have not understood the point of the problem, since your ‘grabtest’ reports that ‘KEYBOARD GRAB FAILED’ for both Qt and GTK.

*** Bug 366281 has been marked as a duplicate of this bug. ***

Confirmed still an issue on latest kdelibs from git master.

I think that is the expected behavior.
If that should be altered, one will need to report that to Qt, but I don't think that will be changed.