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. ***
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?)
*** 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.
why is it not possible to publish fix for kde 3.x+. why shoudl users be forced to wait for kde 4, which is nowhere yet to be released.
Why should a patch for KDE 3 be released? KDE 4 comes in one month, and I'm sure that many users are already using it (me, for instance). If at all, there would be a source code patch, but people who apply source codes rather than installing packages are in most cases programmers. @Andriy Rysin (#27): Keyboard layouts are not the only problem. I do not use different keyboard layouts, but I still find this bug annoying because a very big part of my KDE installation is to be accessed by shortcuts.
Has there been any confirmation or even an indication that kde 4 will fix this problem? It may still be an issue. If it hasn't been fixed in kde 4 its unlikely to be fixed in kde 3... anyway, KDE is still planning to release a 3.5.9 (for some reason) so if there is a workaround, it may still be included in kde 3.
*** Bug 153044 has been marked as a duplicate of this bug. ***
*** Bug 142059 has been marked as a duplicate of this bug. ***
*** Bug 154264 has been marked as a duplicate of this bug. ***
*** Bug 145732 has been marked as a duplicate of this bug. ***
*** Bug 160751 has been marked as a duplicate of this bug. ***
Created attachment 26407 [details] qt4.4.0 patch This Qt patch allows global shortcuts to work while a Qt applications shows a popup, by not grabbing the keyboard when a window from the application already has focus (i.e. it gets already keyboard events anyway). Which means it still doesn't work e.g. with K-Menu or non-Qt applications. There is also the problem that when a popup is open and another one, e.g. from Klipper or the logout dialog, is open, then the new one does not have keyboard/mouse grab (because mouse grab is already taken by the first popup), making the new popup basically useless. It'd probably require manager selection for passing the grab around or something, and it'd be only opt-in.
*** Bug 171116 has been marked as a duplicate of this bug. ***
*** Bug 150442 has been marked as a duplicate of this bug. ***
*** Bug 127751 has been marked as a duplicate of this bug. ***
I can confirm this bug, and it lasts at least one year and something.
This is annoying me, too. The bug is still present in KDE 4.2 Beta2.
The most annoying effect of this bug for me is that I cannot change keyboard layout (I use Win+Z to switch layout) while typing an URL in Firefox or any other browser (because browsers drop down the list when typing in location bar). Since 3.1.94 to 4.2 Beta2 -- not fixed yet -- very pity. If this bug is really hard to fix -- may be use some workaround? For example, could the following option be available to users(?): To make all comboboxes automatically closed when Ctrl, Alt or Win modifier key is pressed. As any global shortcut starts with modifier, this will help. Of course, this is not so handy as processing shortcuts without closing popups -- but it would be much much better than ignoring global shortcuts at all.
Is the patch of Lubos Lunak being accepted - or should someone go and inform Qt Software about this?
I confirm this on KDE 4.2, it happens with firefox url list, as mentioned, but not with same list in konqueror.
Another instance of this bug ... bugging users is the use of keyboard shortcuts for desktop effects. I scroll down a pop up menu and realize that I need to get something from another window in another desktop. I'd like to use the keyboard shortcut to activate the desktop grid (or present windows), but I can't. This is annoying. Thanks in advance for fixing/working on fixing this!
In Kubuntu 9.04 with KDE 4.2 I can say that these features work: 1) When typing in Firefox addressbar with dropdown active, I can switch keyboard layouts with Shift-Alt 2) When typing in Konqueror addressbar with dropdown active, I can switch keyboard layouts with Shift-Alt 3) When typing in Konqueror addressbar with dropdown active, I can switch windows with Atl-Tab 4) When typing in Konqueror addressbar with dropdown active, I can open krunner with Alt-F2 5) When searching in Lancelot's Applications menu, I can switch languages with Shift-Alt 6) When searching in Lancelot's Applications menu, I can switch windows with Atl-Tab And these features do not work: 1) When typing in Firefox addressbar with dropdown active, I can not switch windows with Atl-Tab 2) When typing in Firefox addressbar with dropdown active, I can not open krunner with Alt-F2
*** Bug 190991 has been marked as a duplicate of this bug. ***
*** Bug 193624 has been marked as a duplicate of this bug. ***
> When typing in Konqueror addressbar with dropdown active, I can open krunner with Alt-F2 Still Alt-F2 does not work when recent urls list drop down manuall in address bar. Active popup menu in Konqueror prevents shortucts too.
Works for me in KDE 4.3.3. Thanks for fixing!
(In reply to comment #50) > Works for me in KDE 4.3.3. Thanks for fixing! Doesn't work for me in KDE 4.3.3
works for me in KDE 4.2.2
(In reply to comment #52) > works for me in KDE 4.2.2 Which version of Qt are you using?
Does not work for me with KDE 4.3.3 and QT 4.5.2 (Ubuntu Karmic)
still broken for me on opensuse 11.1. I can't switch windows with m-tab nor switch keyboard layout with c-m-k opensuse 11.1 0 froh@byron:~ $ konqueror --version Qt: 4.5.3 KDE: 4.3.1 (KDE 4.3.1) "release 179" Konqueror: 4.3.1 (KDE 4.3.1) "release 178"
> works for me in KDE 4.2.2 >>Which version of Qt are you using? 4.5.0
*** Bug 223364 has been marked as a duplicate of this bug. ***
Does not work for me. Kde sc 4.4.0 qt-4.6.2-1.fc12.x86_64
I assigned Meta+Arrow keys as global shortcut for volume control. When I have opened e.g. a context menu and decide to change the volume then I cycle through the menu items with the arrow keys instead of changing volume...
I confirm that opening the konqueror location-bar combobox (with the mouse; I'm not talking about the auto-completion popup), and then pressing Alt+F2, does not work. I also confirm that Lubos' patch is not in Qt (I checked 4.6 and 4.7). I just applied it to my Qt-4.6 (it applies cleanly) and restarted konqueror, and .... it works! I can use Alt+F2, switch desktops, etc. Lubos: I guess the reason you didn't send it to Qt (as a merge request or even as a bugreport) is the limitations you mention in comment #36? I can't reproduce the problem you mention with multiple popups, the first one closes whenever I try to open another one.
*** Bug 255909 has been marked as a duplicate of this bug. ***
I think this is not fixable. Popup menus grab keyboard and mouse using X11 calls: XGrabKeyboard and XGrabPointer. KDE will not receive any shortcut events during the time such grab is active.
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. ***
*** 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 [details] grabtest.c
So, as auxsvr@gmail.com 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. ***
*** Bug 380415 has been marked as a duplicate of this bug. ***