Expected behaviour Gnome sends window_state_event when application focus changes. Gtk reacts to it by setting GTK_STATE_FLAG_BACKDROP flag (by ensure_state_flag_backdrop() at gtkwindow.c) to the window which is picked by theme to correctly shade the window. Actual behaviour Gtk applications with CSD enabled (gedit, firefox for instance) does not get window_state_event with focus change so the application looks active even when it's on background. Also default KDE theme does not work well with the "backdrop" state and the theme does not render some elements (scrollbar thumb for instance - https://bugzilla.mozilla.org/show_bug.cgi?id=1491374) Steps to reproduce 1) Open gedit 2) Open another application, make gedit partially visible 3) switch to gedit and back - gedit titlebar does not change its color although it should It also causes issue with Firefox as it uses default theme under KDE which does not render thumb with backdrop state - https://bugzilla.mozilla.org/show_bug.cgi?id=1491374
X or wayland? Also window_state_event is an internal GTK thing, if you can phrase things in terms of the relevant atoms / protocols that's a lot more useful.
Can reproduce this bug on X11 - not on Wayland Operating System: KDE neon Developer Edition KDE Plasma Version: 5.14.80 Qt Version: 5.11.1 KDE Frameworks Version: 5.51.0 Kernel Version: 4.15.0-34-generic
This is out of scope for an X11 window manager.
I suspect KDE does not set _NET_WM_STATE_FOCUSED when the window is running in CSD mode although I didn't look into the KDE sources.
We currently do not set it. But we also don't announce it in our _NET_SUPPORTED which implies something is also wrong on the GTK side to rely on expecting it. >Clients that modify the appearance of internal elements when a toplevel has keyboard focus SHOULD check for the availability of this state in _NET_SUPPORTED and, if it is available, use it in preference to tracking focus via FocusIn events. By doing so they will match the window decorations and accurately reflect the intentions of the Window Manager. It's not available so surely GTK should be falling back to the manual FocusIn tracking?
We do not support _NET_WM_STATE_FOCUSED.
Git commit ce1a5eae156a544da06a9a37ee00b6b55dd13bb3 by David Edmundson. Committed on 10/05/2019 at 14:32. Pushed by davidedmundson into branch 'master'. Support NET_WM_STATE_FOCUSED Summary: This is used by GTK clients to know whether to draw as though they have focus or not. Whilst it's most visible for CSDs headers, use of the active/inactive palette (or backdrop class in GTK terms) applies everywhere. Rationale of the flag is to allow the WM to hint visual states without giving input, i.e so you can hint that the parent of a modal dialog should be shown as active. Though kwin only sets it on the truly active window to match the behaviour our other windows follow. I expect this to be potentially controversial as it's new code in X11, so in advance: * Unlike GTK_FRAME_EXTENTS, it is part of the specificiation (albeit 1.4) even i3 supports it. * It does fix a real world issue * It's only 2 lines (plus trivial boiler plate in kwindowsystem) * It's in code path that we rely on for our existing code * If there's a situation where this does break, the worst that will happen is a client gets a visual hint to have focus incorrectly, which ultimately is the same as the current state Test Plan: Used my CSS for breeze-gtk moved between windows Reviewers: #kwin, rooty, zzag Reviewed By: #kwin, zzag Subscribers: zzag, ognarb, ngraham, rooty, graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D19613 M +1 -0 activation.cpp M +2 -1 netinfo.cpp https://commits.kde.org/kwin/ce1a5eae156a544da06a9a37ee00b6b55dd13bb3