After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 555570 - eats key events when menus open
eats key events when menus open
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: Other
2.14.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 568282 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-08 16:15 UTC by Florian Dorn
Modified: 2010-09-08 13:52 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Florian Dorn 2008-10-08 16:15:48 UTC
Please describe the problem:
If a popup menu is opened, the media keys do not function.

Steps to reproduce:
1. Make sure the media keys function properly with totem, rhythmbox
2. launch rhythmbox, play some song
3. Open a popup menu (e.g.: right click on a song, open Application menu, ...)
4. Press any of the media keys (Play, Pause, Stop, Next, Previous, Volume+, Volume-) and notice that they are not working


Actual results:


Expected results:
The associated action e.g.: Play/Pause should be executed. Popups should not capture media key events.

Does this happen every time?
Happens every time. However wine-popus do not block the media keys.

Other information:
Comment 1 Jens Granseuer 2008-10-08 16:59:36 UTC
Which means that somebody (in this case presumably gtk+) eats the events and keeps gsd from even seeing them.

Probably somewhat related to bug #390312.
Comment 2 Matthias Clasen 2008-10-08 17:02:59 UTC
Menus grab the keyboard, yes.  
But that is not a bug.
Comment 3 Florian Dorn 2008-10-08 17:24:44 UTC
Is there any explanation why popups are so greedy? To my understanding these keys should be always available, like the brightness control keys.
Comment 4 Jens Granseuer 2009-01-19 21:23:12 UTC
*** Bug 568282 has been marked as a duplicate of this bug. ***
Comment 5 Mac Ryan 2010-09-08 13:19:25 UTC
Any news about this? I fully agree with Florian in that the keypress events should be passed further down so that media application can handle them. Why it is not so already / not the behaviour implemented so far?
Comment 6 Emmanuele Bassi (:ebassi) 2010-09-08 13:35:47 UTC
(In reply to comment #5)
> Any news about this?

no: it wasn't a bug, and it still isn't.

 I fully agree with Florian in that the keypress events
> should be passed further down so that media application can handle them. Why it
> is not so already / not the behaviour implemented so far?

because grabs on X11 do not work that way.
Comment 7 Mac Ryan 2010-09-08 13:52:33 UTC
Wow, that was a quick reply... :)
but it was not an answer to what I meant to ask... :(

I shall rephrase my question then: why whoever developed that piece of code has made the choice to implement this functionality that way, and why it has been decided not to address something that from a UI point of view is clearly a flaw [the media keys are equivalent to the mechanical buttons of a tape recorder... the very same symbols are evidence of this]?

Thanks!