| Summary: | Keyboard shortcut ambiguity detected for CTRL+F where there is none | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | kgw |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andresbajotierra, faure, finex, henk, langec, magnus, marcus, mpartap, mss, paul.temple, silvio.frischi, stefano.crocco |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | My (Karl Günter Wünsch) default konqueror profile | ||
|
Description
kgw
2008-12-09 20:16:45 UTC
*Confirmation* for yesterdays SVN checkout. 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. 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. 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... *** This bug has been marked as a duplicate of bug 180108 *** *** Bug 180108 has been marked as a duplicate of this bug. *** 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 *** Bug 178241 has been marked as a duplicate of this bug. *** Still the case with trunk? yup... kinda indeterministic, but yes it does occur sporadically.. 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... 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? @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. 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... Created attachment 30703 [details]
My (Karl Günter Wünsch) default konqueror profile
Ok splitting a view also exposes the bug... For me it looks as if multiple kparts bind their keyboard shortcuts to the same container? Confirmed on a vanilla install of Kubuntu Jaunty-Dev (updated today) with default shortcuts (Konqueror 4.2.00) 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... Musthafa: yes, each conflict is a different issue, please file a different bug. 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 did experience same bug, disappeared after removing kdebase-kio-plugins 4:3.5.9.dfsg.1-6 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. The possible fix (comment 20) will be included into KDE4.2.2 (as it missed KDE4.2.1 by 2 days..) 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. Can anyone else check the behaviour now? Thanks I can't reproduce it any more, using 4.2.4. |