GNOME Bugzilla – Bug 667110
OSD window shown for volume/brightness keys momentarily steals focus, causes Firefox to exit fullscreen mode
Last modified: 2012-01-05 00:54:07 UTC
gnome-settings-daemon listens to hardware volume or brightness keys by showing an on-screen display window with the current volume or brightness level. This window momentarily takes the focus, causing the current window to receive an X FocusOut event followed by an X FocusIn event. Firefox's new support for fullscreen mode (http://blog.pearce.org.nz/2011/11/firefoxs-html-full-screen-api-enabled.html , https://developer.mozilla.org/en/DOM/Using_full-screen_mode) automatically exits fullscreen mode when Firefox loses focus. Since the hardware volume and brightness keys result in a FocusOut event, they cause Firefox to exit fullscreen mode. This problem becomes notable in various common use cases, such as attempting to change the volume while watching a fullscreen YouTube video. You can test this most easily using xev; just run xev from a terminal, make sure it has the focus, hit a hardware volume or brightness key, and notice that xev gets a FocusOut event. The original issue got filed as a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=578265 . However, I don't think Firefox can do anything about this; it has no way to distinguish a FocusOut event caused by GNOME's on-screen display windows from one caused by Alt-Tab or some other focus change that should cause un-fullscreening. The OSD windows for volume and brightness, and any other similar windows which don't need to accept input, should avoid taking the focus when they appear.
Don't set your own bugs on NEW (especially when they're not GNOME bugs) The bug has nothing to do with the OSD window, which is already ignores input events: http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/media-keys/gsd-osd-window.c#n545 You can double-check this yourself: - Run: gsettings set org.gnome.settings-daemon.plugins.media-keys active false - disable all the calls to dialog_show() in gsd-media-keys-manager.c - Run test-media-keys in plugins/media-keys/ You'll see that you still get the focus in/out events even though there's no OSD. The events are an artifact of the key capture, where the root window gets the event instead of your window. You shouldn't jump to conclusions this early in the year...
I only set the bug to NEW because I had confirmation from someone on #xorg-devel that the issue seemed to exist. Also, I didn't realize GNOME used the distinction between UNCONFIRMED and NEW; I figured it remained an artificial distinction of bugzilla's workflow. Sorry about that. The issue remains: hitting the volume or brightness keys causes the active window to receive a FocusOut and a FocusIn, and that needs to not happen. Where should that get fixed, if not in gnome-settings-daemon?
(In reply to comment #2) > I only set the bug to NEW because I had confirmation from someone on > #xorg-devel that the issue seemed to exist. Also, I didn't realize GNOME used > the distinction between UNCONFIRMED and NEW; I figured it remained an > artificial distinction of bugzilla's workflow. Sorry about that. Why bother changing it then? > The issue remains: hitting the volume or brightness keys causes the active > window to receive a FocusOut and a FocusIn, and that needs to not happen. > Where should that get fixed, if not in gnome-settings-daemon? Very likely in X. Seems like the way X works.
(In reply to comment #3) > (In reply to comment #2) > > The issue remains: hitting the volume or brightness keys causes the active > > window to receive a FocusOut and a FocusIn, and that needs to not happen. > > Where should that get fixed, if not in gnome-settings-daemon? > > Very likely in X. Seems like the way X works. Further discussion in #xorg-devel turned up the real culprit: the passive grabs that gnome-settings-daemon uses to capture key events inherently cause FocusOut events when triggered, because they become active grabs to capture the key. However, it turns out that the FocusOut event provides enough information to determine that the event occurred as the result of a grab, and Firefox could use that to determine whether or not to un-fullscreen. In any case, gnome-settings-daemon can't actually do anything to affect this. Sorry for the misdirected bug report. Marking as NOTGNOME.
(In reply to comment #4) <snip> > However, it turns out that the FocusOut event provides enough information to > determine that the event occurred as the result of a grab, and Firefox could > use that to determine whether or not to un-fullscreen. In any case, > gnome-settings-daemon can't actually do anything to affect this. Out of curiosity, what information would that be? > Sorry for the misdirected bug report. Marking as NOTGNOME. No worries.
(In reply to comment #5) > (In reply to comment #4) > <snip> > > However, it turns out that the FocusOut event provides enough information to > > determine that the event occurred as the result of a grab, and Firefox could > > use that to determine whether or not to un-fullscreen. In any case, > > gnome-settings-daemon can't actually do anything to affect this. > > Out of curiosity, what information would that be? The FocusOut event includes a .mode field, which contains NotifyGrab when the FocusOut occurred as the result of a grab. Switching windows by clicking will produce a FocusOut with NotifyNormal, and switching windows via Alt-Tab results in first a FocusOut with NotifyGrab (due to the grab of Alt-Tab) followed by a FocusOut with NotifyWhileGrabbed (when the window manager actually changes the focus). xterm gets this right: it ignores FocusOut events with mode NotifyGrab, and thus pressing a grabbed key such as a hardware volume key does not cause xterm to show the hollow cursor it normally shows when it doesn't have the focus. gnome-terminal gets this wrong: it flashes the hollow cursor when hitting a hardware volume key or other grabbed key. So, Firefox just needs to filter out FocusOut events with mode NotifyGrab. Discussion on #xorg-devel and #gtk+ suggested that GDK/GTK+ should probably also fix this internally to avoid having to fix it in every individual application that cares about losing focus. Rui Matos said he already planned to try to fix this.