When a menu is opened, KDE & Konqueror shortcuts stop working

[kko]

Binary package hint: kdebase

In konqueror:

1. Open up "Location" -menu, either with mouse or with "Alt-L".

2. You will see the option "New Window _____ Ctrl-N", if you pressed Alt-L it will be highlighted too, by default. (With mouse you could have something else highlighted.)

3. Press Ctrl-N.

-> No response.

4. Press Ctrl-Fx to switch desktop.

-> No response.

I see no reason for keyboard shortcuts to stop working, when a menu (showing the very same shortcuts, none-the-less!) is open.

I suspect this is a wider KDE issue than just konqueror.

For the same issue in Gnome please see bug 32860.

[kko (kko)]

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

[kko (kko)]

P.S. Kubuntu Breezy with KDE 3.4.3.

[kko (kko)]

Note: This is somewhat related to bug 45483, but IMO still warrants an own report.

[Frode M. Døving (frode)]

Confirmed on current dapper. KDE 3.5.2

[Luka Renko (lure)]

konqueror is part of kdebase source package, therefore it is already assigned to appropriate package.

[Luka Renko (lure)]

Is this the bug that just got fixed upstream?
http://bugs.kde.org/show_bug.cgi?id=80584

[kko (kko)]

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

[kko (kko)]

Comment on 2006-05-21 should refer to bug 45843.

[Ralph Janke (txwikinger)]

Still working like this in hardy with KDE 3.5.9

[Ralph Janke (txwikinger)]

Same problem in KDE 4.1 Beta2

[kko (kko)]

Harald Sitter: I see you've marked this as a duplicate of bug 45843. These have been duped and unduped before, unduped for the reason that it may be a different part of the code that is responsible for what happens with keyboard shortcuts when a) a context menu, and b) a regular menu are opened. With this in mind, could you provide your reasoning for why you think the duplicate status is warranted, please.

Oh and Ralph Janke, thanks for checking and re-confirming these two in the newest releases, esp. 4.1 beta 2.

[Harald Sitter (apachelogger)]

Certainly.
This kind of stuff is controlled by the toolkit, rather than the application. In fact I just fired up all my VM's and checked - neither Windows, nor GTK+ actually provide this functionality either. So, if this should ever be considered a better default than the current default (I really think this "bug" is more of a feature than a bug), where you cannot use shortcuts form within context menus, it would have to be fixed at either the Qt or KDELibs level.
And some more generic reason: bug 45843 is describing the general problem while this bug is describing the general problem in a Konqueror use case, which makes this bug less useful than bug bug 45843.

[kko (kko)]

Thank you for the answer. I'm aware that this is toolkit-dependent. However, I think you may be missing the original distinction. It is not between "general" and "general in Konqueror", but between regular menu's (File, Edit, Show, etc., accessed from the top of the window) - addressed in this bug - and context menu's (accessed through a mouse right-click) - described in bug 45843.

[Harald Sitter (apachelogger)]

Nope.
They menu = menu, eventually the context menu might be themed differently, but they are the very same base type = menu.

[kko (kko)]

Very good, thank you for the information.