brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

frames: Double check _MUTTER_NEEDS_FRAME property changes

Browse Source 
Recalculating window features is a busy thing on the Mutter side, the
different properties being (re)set will overwrite the current state
and cause some side work. Between that is the rewriting of the
_MUTTER_NEEDS_FRAME property on the window being recalculated, which
throws the frames client off, by thinking the window does actually
require a new frame.

It is not sufficient to trust that PropertyNewValue means the property
or the value are new, also double check that the window did not have
in fact a frame, and avoid the busy work if it did.

Besides the busywork that can be easily avoided, this also fixes the
window close button state being stuck if the window changed its
deletable state, since the frame being respawn managed to miss the
property change.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
This commit is contained in:
Carlos Garnacho 2022-12-02 19:59:21 +01:00
parent 381de44c5d
commit 6c0254bf02
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/frames/meta-window-tracker.c
View File

@ -214,9 +214,13 @@ on_xevent (GdkDisplay *display,
xevent->xproperty.atom ==
gdk_x11_get_xatom_by_name_for_display (display, "_MUTTER_NEEDS_FRAME"))
{
if (xevent->xproperty.state == PropertyNewValue)
if (xevent->xproperty.state == PropertyNewValue &&
!g_hash_table_contains (window_tracker->client_windows,
GUINT_TO_POINTER (xwindow)))
set_up_frame (window_tracker, xwindow);
else if (xevent->xproperty.state == PropertyDelete)
else if (xevent->xproperty.state == PropertyDelete &&
g_hash_table_contains (window_tracker->client_windows,
GUINT_TO_POINTER (xwindow)))
remove_frame (window_tracker, xwindow);
}
else if (xevent->type == PropertyNotify)