Panel sets WM_HINTS.input=True, can become _NET_ACTIVE_WINDOW instead of newly-mapped windows

Summary

The panel window advertises WM_HINTS.input = True together with _NET_WM_WINDOW_TYPE_DOCK. Under xfwm4 on X11 this can result in the panel itself becoming _NET_ACTIVE_WINDOW when new application windows are mapped, so newly-launched windows do not receive keyboard focus.

Steps to reproduce

  1. Fresh LMDE 7 install (Xfce 4.20, xfwm4 default).
  2. Log in as a brand-new user (no custom config).
  3. Open any application (terminal, file manager, browser — anything).
  4. Start typing.

Expected: keystrokes go to the new window. Actual: keystrokes go nowhere; xdotool getactivewindow getwindowname returns the panel.

Reproducer notes

  • Reproduces with vanilla xfce4-panel and xfwm4, no plugins, no third-party configs
  • Reproduces in a fresh user account, so it is not a stale-config issue
  • Reproduces with both click_to_focus and focus follows mouse
  • Single monitor, single panel positioned at the bottom
  • "Focus new windows when created" is enabled

Diagnostic output

xprop on the panel window:

WM_HINTS(WM_HINTS): Client accepts input or input focus: True

Initial state is Normal State.

window id # of group leader: 0x1e00001

_GTK_THEME_VARIANT(UTF8_STRING) = "dark"

XdndAware(ATOM) = BITMAP

_NET_WM_OPAQUE_REGION(CARDINAL) =

_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x0, 0x0, 0x0

WM_WINDOW_ROLE(STRING) = "Panel"

_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK

The combination WM_HINTS.input = True + _NET_WM_WINDOW_TYPE_DOCK is inconsistent . A dock should not claim to want input focus. Other dock-style applications (tint2, polybar, plank) all set WM_HINTS.input = False.

Likely cause

panel_window_init() in panel/panel-window.c sets up the GtkWindow but never calls gtk_window_set_accept_focus(window, FALSE). With GTK's default of accept_focus = TRUE, the panel's WM_HINTS.input stays True, which xfwm4 appears to honour for _NET_ACTIVE_WINDOW selection in some circumstances.

Workaround / fix

Adding the following line inside panel_window_init() (immediately after the existing gtk_window_set_resizable() call) resolves the symptom completely:

gtk_window_set_accept_focus (GTK_WINDOW (window), FALSE);

After applying this patch and restarting the panel, xprop reports Client accepts input or input focus: False, and new windows receive focus as expected. Tested locally on a rebuilt 4.20.4 package; no regressions observed in panel interaction (clicking plugins, opening menus, etc. all still work — this only changes the WM_HINTS hint sent to the WM).

Environment

  • Distribution: Linux Mint Debian Edition 7
  • xfce4-panel: 4.20.x (LMDE 7 default)
  • xfwm4: LMDE 7 default (X11 session)
  • GTK: 3.x
  • Hardware: ThinkPad T14 Gen 2 intel, single monitor

Note

This may explain a long tail of "panel/focus issues" reports on the Xfce forum that have historically been closed as user-config problems (e.g. forum thread 9227, 19008). It reproduces in fresh user accounts and is independent of user configuration.