GNOME Bugzilla – Bug 780292
window: Always sync window geometry on state change
Last modified: 2021-07-05 13:48:37 UTC
This fixes a bug where the fullscreen transition in gnome-shell gets stuck when fullscreening a window that is already the size it would have if fullscreened. It's easiest to reproduce when there are two monitors: 1. Move a maximizable and fullscreenable window to the external monitor (without shell chrome) 2. Maximize that window 3. Fullscreen that window This will cause the fullscreen transition actor to never be unmapped. This is because a 'size-change' event is seen, triggering the fullscreen animation, but it never progresses, since 'size-changed' is never emitted.
Created attachment 348296 [details] [review] window: Always sync window geometry on state change When a state changed, e.g. a window went from unfullscreen to fullscreen, always sync the window geometry, otherwise a compositor application (e.g. gnome-shell) might end up with an unfinished window state transition effect. Without always syncing, the compositor plugin will see a 'size-change' event, as a result of the state change, but if the size didn't change, it would never see the 'size-changed' event. If an effect, for example gnome-shell's fullscreen effect, is triggered on 'size-change' it might rely on the actual size change to not get stuck. This commit allows it to have this dependency. This fixes a bug where a fullscreen effect gets "stuck" when a window goes fullscreen without changing the window geometry.
Review of attachment 348296 [details] [review]: makes sense
Attachment 348296 [details] pushed as 5d3e7d6 - window: Always sync window geometry on state change
This regressed size change animations for wayland windows.
Created attachment 353759 [details] [review] window: For wayland clients sync window geometry on commit Otherwise wayland clients size change animations don't work properly since we are syncing the window actor geometry twice, first with the old size and then finally with the new size when the commit arrives.
Hopefully this doesn't re-introduce the bug we were fixing here in the first place.
Review of attachment 353759 [details] [review]: ::: src/core/window.c @@ +3649,3 @@ +#ifdef HAVE_WAYLAND + if (window->client_type == META_WINDOW_CLIENT_TYPE_WAYLAND) + return (flags & META_MOVE_RESIZE_WAYLAND_RESIZE) != 0; I think this will mean we'll call into Javascript too often. This is mostly due to us being to liberal with calling meta_window_wayland_move_resize() in src/wayland/. Currently we'll call it on every commit for popups, and on every commit the client sets the window geometry. That is probably a bad idea. In practice, with this, it'd mean we'd enter JS on every commit, as GTK+ sets the (same) window geometry on every commit, triggering meta_window_wayland_move_resize(), ending up here, causing the 'size-changed' signal to be emitted, ending up in windowManager.js. To fix this, we need to make MetaWaylandXdg(Toplevel|Popup) know when to actually call move_resize(), thus teaching it about what configure-acks actually changes and/or are state-change acks. Eventually it'd be nice to redesign all of the MetaWindow state tracking to hide away display protocol differences, making every potentially asynchronous operation asynchronous in the API too, but that's for another time I guess.
*** Bug 786028 has been marked as a duplicate of this bug. ***
*** Bug 786552 has been marked as a duplicate of this bug. ***
*** Bug 788642 has been marked as a duplicate of this bug. ***
*** Bug 789948 has been marked as a duplicate of this bug. ***
*** Bug 790231 has been marked as a duplicate of this bug. ***
*** Bug 791698 has been marked as a duplicate of this bug. ***
*** Bug 792697 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.