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 667110 - OSD window shown for volume/brightness keys momentarily steals focus, causes Firefox to exit fullscreen mode
OSD window shown for volume/brightness keys momentarily steals focus, causes ...
Status: RESOLVED NOTGNOME
Product: gnome-settings-daemon
Classification: Core
Component: keybindings (obsolete)
3.2.x
Other All
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2012-01-02 01:19 UTC by Josh Triplett
Modified: 2012-01-05 00:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Josh Triplett 2012-01-02 01:19:43 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.
Comment 1 Bastien Nocera 2012-01-02 12:11:38 UTC
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...
Comment 2 Josh Triplett 2012-01-02 23:40:31 UTC
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?
Comment 3 Bastien Nocera 2012-01-04 16:33:46 UTC
(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.
Comment 4 Josh Triplett 2012-01-04 20:54:00 UTC
(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.
Comment 5 Bastien Nocera 2012-01-04 21:01:42 UTC
(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.
Comment 6 Josh Triplett 2012-01-05 00:54:07 UTC
(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.