Thanks for your bug. That's not a bug and not specific to this feature (try to
alt-tab with the menu open by example). GTK needs to grab the keyboard events
for the menu accelerators.

I don't get why this shouldn't be a bug.
In my opinion, this is a very ennoying bug.

Example:
When I listen to a playlist while navigating through menus in another application and the next song in the list that is played is to loud (e.g.), I want to be able to turn down the volume fast (with the help of the volume-down-key on my keyboard) and without having to close all the menus.

I suggest reopening the bug. 
+ http://bugzilla.gnome.org/show_bug.cgi?id=144907 is a valid bug and assigned.

(In reply to comment #2)
> I don't get why this shouldn't be a bug.
> In my opinion, this is a very ennoying bug.

it's not a bug, it's a side effect of the required behaviour of the menus in gtk+; without it, you wouldn't be able to navigate in menus using your keyboard.

read the explanation in comment 2.

I've read comment 2 but (as said) I can't quite follow the arguments. 

* »(try to alt-tab with the menu open by example)«
  -> Well... Nothing happens. (What did you expect to happen?) I would expect that either the menu is closed and the focus switches to the next window or even better: The menu stays open is and the focus switches

* »GTK needs to grab the keyboard events for the menu accelerators.«
  -> Right. But none uses the print key or any other multimedia keys as menu accelerator!? + only single keys are used as menu accelerators (provided that I understand the term »menu accelerator« correctlys. Menu accelerators are the underlined letters of menu entrys?) so there's no reason for Ctrl+X Alt+X,... not to work.

My point is that no single shortcut works while a menu is open.

Example I: (concerning »navigation in menu using your keyboard«)
1) Open a menu by using Alt+F
[see: _Print  ...  Ctrl+P. Recognize the big Ctrl+P rather then the little line under the p as shortcut/accelerator.]
2) Press Ctrl+P to print.
[notice: nothing happens. Unexpected!]
3) Use the arrow keys to navigate to »Print« (this is what the not-that-advanced-users tend to do) OR Press p 
  -> the print dialog opens as expected.

Example II:
1) Open a menu (Alt+F)
2) Navigate to a sub menu and search the menu for a specific entry.
[imagine: the entry you look for is not in this menu. think: then it has to be in the »_Tools« menu]
3) Try to open the Tools menu by using Alt+T.
[notice: nothing happens]
4) Try to open the Tools menu by pressing T
[notice: the »Impor_t Wizard« pops up. Unintentional!]
[Either you know that you have to press the arrow-right key several[1] times to go to the Tools menu or you try the following:]
5) Try to focus »File« using the arrow (up/down) keys. Doesn't work. Use the mouse to do that. Press T. It finally works and you're in the Tools menu.

I hope you got what my arguments are... It's almost as frustrating to do something and see ... nothing ... happen as it is to see that something unexpected happens.

Imho this is even worth a new bug because (as explained in ~40 lines) it does not only affect the print/... key but all shortcuts.



[1] The bad thing about this is: You don't know how many times you have to hit arrow-right to get where you want until you do it, because the first menu item could be a sub-menu (try to go from »File« [Alt+F!] to »Help« in Evolution for example)