Bug 177332 - Keyboard shortcut ambiguity detected for CTRL+F where there is none
Summary: Keyboard shortcut ambiguity detected for CTRL+F where there is none
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 178241 180108 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-09 20:16 UTC by kgw
Modified: 2009-07-07 23:00 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
My (Karl Günter Wünsch) default konqueror profile (2.83 KB, text/plain)
2009-01-29 13:31 UTC, kgw
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kgw 2008-12-09 20:16:45 UTC
Version:            (using Devel)
Installed from:    Compiled sources

When pressing CTRL+F inside a khtml window the message "The key sequence 'Ctrl+F' is ambiguous. Use 'Configure Shortcuts'
from the 'Settings' menu to solve the ambiguity.
No action will be triggered." appears. Looking through the configured shortcuts reveals that there is no conflict with any other short cut (all default as installed).
Comment 1 Marcel Partap 2008-12-13 18:15:07 UTC
*Confirmation* for yesterdays SVN checkout.
Comment 2 kgw 2008-12-15 00:10:11 UTC
I may have a clue what conflict happens: If I only press CTRL then the assigned short cuts for accessibility are displayed and the F key is assigned there as well. This may be the reported conflict which will only happen on web pages with many links - which is probably why on simple pages the conflict is not reported.
Comment 3 Malte S. Stretz 2008-12-23 20:49:05 UTC
Can you still reproduce this with 4.2-beta2?  If so, on which pages?  Here I can't trigger this bug though the similar bug 176206 (Ctrl++)  is triggered.
Comment 4 kgw 2008-12-24 09:50:06 UTC
Yes, I still can reproduce the bug. But now it only shows while I haven't looked at any of those sites I load initially from the browser profile (I open 6 pages initially: www.kde.org , http://www.dforum.net/forumdisplay.php?f=18 , http://www.naturescapes.net/phpBB3/viewforum.php?f=5 , http://www.naturephotographers.net/imagecritique/ic.cgi?a=vg3&u=12493 , http://forums.dpreview.com/forums/forum.asp?forum=1019 and http://www.fotocommunity.de/forum/list.php?f=59
After clicking on the tab for each of them the conflict disappears and CTRL+F works as expected...
Comment 5 Dario Andres 2009-01-09 14:17:25 UTC

*** This bug has been marked as a duplicate of bug 180108 ***
Comment 6 Dario Andres 2009-01-09 14:41:48 UTC
*** Bug 180108 has been marked as a duplicate of this bug. ***
Comment 7 Dario Andres 2009-01-09 14:45:18 UTC
As stated in bug 180108, I can reproduce this using:

Qt: 4.4.3 + qt-copy-patches-889120
KDE: 4.2.60 (KDE 4.2.60 (KDE 4.3 >= 20090106))
kdelibs svn rev. 908156 / kdebase svn rev. 908156
on ArchLinux x86_64 - Kernel 2.6.27.10
Comment 8 FiNeX 2009-01-09 19:17:47 UTC
*** Bug 178241 has been marked as a duplicate of this bug. ***
Comment 9 David Faure 2009-01-29 02:18:27 UTC
Still the case with trunk?
Comment 10 Marcel Partap 2009-01-29 03:07:57 UTC
yup... kinda indeterministic, but yes it does occur sporadically..
Comment 11 kgw 2009-01-29 09:10:42 UTC
It's not sporadically, I can reproduce this each and every time! Just open konqueror with a profile that itself contains several tabs. Now try to use the shortcut on the topmost tab (whatever that may be). You have to have viewed each and every tab that came up initially and the key combination is useable...
Comment 12 David Faure 2009-01-29 11:52:51 UTC
I couldn't reproduce this.
Well I don't have such a profile so I simply started konqueror with a command-line like
konqueror www.kde.org www.koffice.org www.google.com

Ctrl+F seems to work fine then, even before I visit all tabs.

Can you confirm this?

Does the problem only happen on sites with frames, maybe?
Comment 13 Marcel Partap 2009-01-29 13:11:49 UTC
@kgw: maybe you could attach your konq profile /konquerorrc file as a test case?
Also you might try to update all kdebase packages to the same revision..

@david: well for me it doesn't seem to depend on the views or kparts loaded.. within a session (which can last several days during which i also svn up all kde packages regularly, including kded) it just suddenly starts reporting that error.. will pay more attention to the circumstances when it comes up next time.
Comment 14 kgw 2009-01-29 13:27:47 UTC
Well it happens for the tree sites you tried as well. Although somehow the profile i have seems botched, I want to have konqueror to come up with the same sites every time I open it. If I now try to open these three sites from your example I get tabs for several pages that stay empty. Either I would expect the additional tabs to be filled with the sites I have saved in my profile or not appear at all...
I am on KDE 4.2 release version "Version 4.2.00 (KDE 4.2.0)"
I'll attach my default profile to this bug...
Comment 15 kgw 2009-01-29 13:31:43 UTC
Created attachment 30703 [details]
My (Karl Günter Wünsch) default konqueror profile
Comment 16 Marcel Partap 2009-02-08 18:45:28 UTC
Ok splitting a view also exposes the bug... For me it looks as if multiple kparts bind their keyboard shortcuts to the same container?
Comment 17 Kubuntiac 2009-02-22 02:40:30 UTC
Confirmed on a vanilla install of Kubuntu Jaunty-Dev (updated today) with default shortcuts (Konqueror 4.2.00)
Comment 18 Unknown 2009-02-27 09:29:26 UTC
I have a similar ambiguity problem in KMail...

In the Message window, after opening the search window using ctrl+f, if we press 'Esc', I get the below error message. I checked the 'Configure Shortcuts', but 'Esc' is assigned to only one operation 'Abort Current Operation' !

"The key sequence 'Esc' is ambiguous. Use 'Configure Shortcuts'
from the 'Settings' menu to solve the ambiguity.
No action will be triggered."

Should I have to raise a new bug for this?

Thanks a lot...
Comment 19 David Faure 2009-02-27 12:57:48 UTC
Musthafa: yes, each conflict is a different issue, please file a different bug.
Comment 20 David Faure 2009-02-27 21:54:56 UTC
SVN commit 933031 by dfaure:

Fix shortcut clashes when splitting the konq window; the default "window context" is too much, restrict shortcuts to "when this widget or a child of it has focus"
CCBUG: 177332


 M  +5 -0      khtml_part.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=933031
Comment 21 henk löke 2009-03-14 14:03:05 UTC
did experience same bug, disappeared after removing kdebase-kio-plugins 4:3.5.9.dfsg.1-6
Comment 22 Silvio Frischknecht 2009-03-25 14:14:24 UTC
i can still reproduce this in kde 4.2.1 gentoo amd64. here it appeares if you have several tabs open then killall konqueror (or s.th like that, just a crash) and then start konqueror and click on restore session.
Comment 23 Dario Andres 2009-03-25 20:07:04 UTC
The possible fix (comment 20) will be included into KDE4.2.2 (as it missed KDE4.2.1 by 2 days..)
Comment 24 kgw 2009-07-01 20:38:15 UTC
I can no longer reproduce on either KDE 4.2.4 or KDE 4.3 RC... I thus assume that the fix that went into KDE 4.2.2 did in fact fix this issue.
Comment 25 Dario Andres 2009-07-07 21:34:32 UTC
Can anyone else check the behaviour now? Thanks
Comment 26 Christoph Lange 2009-07-07 23:00:34 UTC
I can't reproduce it any more, using 4.2.4.