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

Bug #45843 reported by kko on 2006-05-21
32
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KDE Base
Fix Released
Medium
kdelibs
Confirmed
Medium
kde4libs (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: kdebase

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.

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. ***

27 comments hidden view all 115 comments
kko (kko) wrote :

I would like to set the "Affects" -field to include both kdebase (for the Desktop) and konqueror. How do you do that?

kko (kko) wrote :

P.S. Kubuntu Breezy with KDE 3.4.3.

kko (kko) wrote :

Note: For a similar phenomenon with regards to normal menus (i.e. not context menus), please see bug 45846. These bugs are IMO however distinct.

Frode M. Døving (frode) wrote :

Confirmed on current dapper. KDE 3.5.2

Changed in kdebase:
assignee: nobody → kubuntu-team
status: Unconfirmed → Confirmed
Luka Renko (lure) wrote :
kko (kko) wrote :

After reviewing the upstream bug report, I have to say that it doesn't seem to be related. This bug has no relation to a "navigation panel" / "tree view" in Konqueror, and I do not use such an option.

23 comments hidden view all 115 comments

This behavior is still present in KDE 3.5.3 ...

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?)

24 comments hidden view all 115 comments
kko (kko) wrote :

Sarah Hobbs: I see you've marked this as a duplicate of bug #45846.

There is a difference between this bug and bug #45846, which you've probably noticed. But I'll reiterate: one is about context menus and the other about regular menus.

Now, I am not confident the same piece of code that fixes one would necessarily fix the other. Unless proven otherwise, I'd judge it most probable that a different part of the code handles (or not, as is the case) keyboard events during context menus, while another part determines what happens with keypresses when a regular application menu is open.

I'd therefore prefer if these two reports were kept open separately. (I happen to know you do regular bug triage here, so I won't revert your changes, but I would seriously appreciate if you reconsidered this one.)

(I also see, now, that the discussion in the KDE bug referenced (by Luka Renko) mixes in lots of different types of "shortcuts not working when {condition X}" issues. With regard to that bug, KDE 80584, at least its title referring to "when focus is on the navigation panel" seems completely misleading towards both of the Launchpad bugs here, and I'm not at all confident that these are about the same issue.)

kko (kko) wrote :

Related KDE bugs:
127751 (for Konqueror)
127752 (for KDE Desktop)

Unfortunately you can only set one "kdebase (upstream)" task currently. (I can see the reasoning, but it would've been practical in this case...)

Fair enough. Unduped.

Thanks for filing/finding the upstream bug.

er, bugs.

Have manhandled launchpad into accepting and tracking both bugs - I know they both should be under KDEBase, but that will work.

Changed in kdebase:
status: Unknown → New
Changed in kdelibs:
status: Unknown → Confirmed
22 comments hidden view all 115 comments

*** 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.

28 comments hidden view all 115 comments
Ralph Janke (txwikinger) wrote :

Still occurs the same way in KDE 3.5.9 and KDE 4.1 beta2

Changed in kdebase:
status: Confirmed → Triaged
Changed in kdebase:
assignee: kubuntu-team → nobody
Changed in kdebase:
status: New → Invalid
Changed in kdebase:
importance: Medium → Low
Changed in kdebase:
status: Invalid → Unknown
Changed in kdebase:
status: Unknown → Confirmed
Jonathan Thomas (echidnaman) wrote :

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. But don't worry! This issue is being tracked by the KDE developers at: http://bugs.kde.org/show_bug.cgi?id=70063 and http://bugs.kde.org/show_bug.cgi?id=127752
Once fixed in KDE, it will be included in Kubuntu once the KDE version the fix is in in reaches Kubuntu.

Thanks!

Changed in kde4libs (Ubuntu):
status: Triaged → Invalid
Changed in kdelibs:
importance: Unknown → Medium
Changed in kdebase:
importance: Unknown → Medium
63 comments hidden view all 115 comments

ultr: obviously it's not that simple, since the patch from #36 works. If I read it correctly, it makes popups not grab the keyboard when they don't need to (because the popup is the active window anyway, so it will get keyboard events) -- but I'm not very good at reading Xlib-related code.

Yes, but this only solves the problem in Qt programs. If GTK application continues to grab the keyboard, there is probably nothing KDE can do about it.

The Global shortcuts should take priority over any pop-up or pop-over layers or
menus, even if contextual.

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

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. ***

Changed in kde-baseapps:
status: Confirmed → Unknown

*** 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.

Changed in kde-baseapps:
status: Unknown → Fix Released

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. ***

Displaying first 40 and last 40 comments. View all 115 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.