GNOME Bugzilla – Bug 772729
[wayland] mutter/gnome-shell relocates windows after they're mapped on screen
Last modified: 2016-10-12 08:17:32 UTC
Description: This seems to be a recent regression in mutter-3.22.x (I did not notice that in 3.20), it seems in a multii-monitor setup, mutter relocates windows after they're mapped, which is confusing to the user. Steps to reproduce: - Log into GNOME on Wayland with a dual monitor setup. - In the primary monitor, open the gnome-control-center and move the pointer quickly to the second monitor Actual result: The gnome-controll-center window shows up on the primary monitor for second andthen moves to the second monitor Expected results: Once mapped, the window remains where it is.
Same with pretty much any application actually, just reproduced with gnome-calculator launched from the dash.
Created attachment 337391 [details] Screencast of the issue The screencast makes the problem very visible...
I'm seeing this for a single-monitor setup too. In this case the relocation isn't that obvious because it is just like 20 pixels, but it is still present. I can confirm this bug doesn't affect other (Gtk+ 2.x, Qt4 or Gtk+ 3.x with GDK_BACKEND=x11) toolkits and backends. This is a list of some applications I've tested with every window I could find to open: * gnome-terminal: * about dialog * search dialog * profile settings dialog * preferences dialog, but only when opened from menu, not from appmenu * NOT affected: * new window * evince: * shortcuts window * about dialog * NOT affected: * document properties dialog * file open/save dialogs * document properties dialog * nautilus: * preferences dialog * shortcuts window * about dialog * NOT affected: * folder/file properties dialog * new window Some more places I've noticed this: * gnome-control-center main window * gnome-control-center shortcuts window * gnome-calendar event editor dialog * evolution about dialog * yelp main window (at least when called from evince appmenu or nautilus appmenu)
The regression was introduced after 3.21.91 as this version was not affected. 3.21.92 has the bug though. git bisect gives: 4f58a4621725ac657dcfa1e232af4e0d063b8f76 is the first bad commit commit 4f58a4621725ac657dcfa1e232af4e0d063b8f76 Author: Olivier Fourdan <ofourdan@redhat.com> Date: Wed Apr 6 14:07:08 2016 +0200 wayland: add min/max size from xdg-shell v6 Implement min/max size request from xdg-shell-v6 and plug it into the existing code so that windows with fixed size cannot be tiled/maximized in Wayland just like in X11. Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=770226 Oops... :(
Created attachment 337430 [details] [review] [PATCH] wayland: apply size hints after placing the window Otherwise the window will be shown initially in the wrong position then moved quickly as soon as it's made visible, which is confusing.
Review of attachment 337430 [details] [review]: Looks good to me.
Comment on attachment 337430 [details] [review] [PATCH] wayland: apply size hints after placing the window attachment 337430 [details] [review] pushed to git master as commit d7f61e4 - wayland: apply size hints after placing the window