Version: (using KDE Devel) Installed from: Compiled sources If you are typing something in the location-box, and press CTRL+A, I expect it used to select all the text in location box. This is usefull for clearing the location or copying it to another context. This worked in all version of KDE 3.x In KDE 4, this short-cut is no longer caught by the location box, but is instead caught by the KPart, selecting all text on the current page.
ditto for Ctrl+U that should clear the line box. Grmmbl.
the problem here is that we have a bad workaround in place for a Qt bug. Widgets with windowType() == Popup steal keyboard focus on creation even if they are explicitely setFocusPolicy(NoFocus). This is why, for instance, the input cursor disappears from lineedits when the completion popup appears. Someone just made a crude workaround in kcompletionbox redirecting keyboard events in the completion's eventFilter back to the line edit. That is apparently messing with shortcuts. I think the original Qt bug is very bad for completion-like widget implementations so should be addressed in Qt asap, but it should be possible to come up with a better workaround. Looking into that.
mmh, I got over enthusiastic. The described Qt bug and workaround doesn't really affect the shortcuts. I got lured by the fact that while the completion box is displayed, the standard linedit shortcuts do work normally in konqcombo.
*** Bug 152950 has been marked as a duplicate of this bug. ***
*** Bug 151553 has been marked as a duplicate of this bug. ***
*** Bug 153912 has been marked as a duplicate of this bug. ***
*** Bug 154129 has been marked as a duplicate of this bug. ***
*** Bug 154694 has been marked as a duplicate of this bug. ***
SVN commit 757275 by ggarand: fix ctrl+A not working in location bar initial patch from Matt Rogers, with enlightning input from Hamish Rodda leading to solution. BUG:153114 M +3 -0 khtml_part.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=757275
I'm not sure where to add this comment, so if it is better to put it somewhere else, let me know (I'm on the cc list). This bug still exists on konqueror 3.5.9 / kde 3.5.10 on Debian 5.0. (Which belies the first comment above which says it worked correctly in all versions of kde 3.5.) Is there any (reasonable) chance this will get fixed for kde 3.5.10? Hmm, I don't see a way to reopen this bug--do I lack permissions or must I create a new bug? I suppose I'll create a new bug.
I'm retracting my previous statement, at least mostly. I had this problem when I installed Debian 5.0 for the first time (and incidentally, or not (??), chose the Unix option (characterized by "Focus (strictly) follows mouse")). I've since reinstalled Debian 5.0, for this and some other KDE GUI related reasons (I'll elaborate more on those sometime in the future, probably on a mail list). On the reinstall, I chose the KDE option (characterized by "Focus on Click"). Also, going back to the first install, I didn't try to record every change I made with respect to the KDE GUI behavior. Anyway, the bottom line is: * <ctrl> a / select all works for me in the konqueror location bar * I don't know exactly what made the difference on this reinstall