GNOME Bugzilla – Bug 504692
Windows open on one display, then jump to another on first click
Last modified: 2012-08-16 13:11:45 UTC
Please describe the problem: I'm currently running Metacity 2.21.2 from Hardy, and I'm experiencing an odd issue with a multi-monitor configuration. My two monitors are side-by-side, and windows tend to open first on the left monitor, then once it's occupied they'll start on the right monitor. The weirdness is that the window that opens on the right monitor (often firefox for me, but seems to affect others as well) jumps to the other monitor on the first mouse click event. The click itself is delivered to the window - I know this because the first thing I usually do when I open Firefox is toggle the quickproxy status on the status bar. The status changes, thus I know the click event wan delivered and handled despite the window moving. Steps to reproduce: This seems very reproducible for me. I open two applications which maximize on startup, the first will be on the left monitor and the second one on the right. One click on the app on the right moves it to the left monitor, still maximized. Actual results: Expected results: Does this happen every time? Other information:
I was working on the reproducibility of this yesterday, and realized that it seems to only work predictably when this open sequence is the first thing you do after session login. I've definitely seen it happen after that, but immediately after session login *always* does this as described. Also, maybe related or maybe just another bug, *any* window I open that is automatically maximized seems to open initially on the right monitor, then just to the left before the image is even fully rendered on the screen. It's the same jump thing I described above but the window doesn't linger on the right monitor before moving. Any ideas?
I've seen this (window jumping to the left monitor after opening on the right), particularly with evolution, probably because it's the first app that I type in after logging in, or the first full-screen app. I type in the URI and at the moment I hit enter, the window jumps to the left monitor. I guess it could also be to do with the drop-down box with history/search options that shows up below the address entry field. I'm using metacity 2.21.5 with the compositor enabled, built by me using the Debian 1:2.20.1-1 packaging but without its as-needed patch (the -Wl,--as-needed flag is still set in the debian/rules file). I didn't have this behaviour with the metacity 1:2.20.1-1 Debian package. Let me know if there is any more information I can provide.
I bisected this and the bug was introduced in revision 3391, attachment #98853 [details] on bug #461927.
Created attachment 113171 [details] [review] Patch: ensures the user_rect is set sensibly for windows that start maximised
Downstream bug reports: Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=444754 Ubuntu: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/224845
Created attachment 116036 [details] [review] Prevent maximised windows warping to the left monitor While attachment #113171 [details] was smaller, I wasn't really comfortable with the magic behaviour of calling meta_window_get_client_root_coords() directly. Sure there was a comment explaining it, but I think this ends up being easier to understand. The first two hunks provide clear function names for setting the user_rect ("window placement"), the third provides the actual logic and the last just updates another call to the renamed function. There is one additional difference, this patch will set the user_rect on initial placement even if the window is fullscreen. The previous patch would leave the user_rect unset in that case, which I think was unwise and might have led to similar warping for fullscreen windows. Perhaps attachment #113171 [details] is more appropriate for a stable branch. (Somewhat inspired by "Coding without comments" <http://www.codinghorror.com/blog/archives/001150.html>)
Ted: Sorry to have been so long getting back to you. I like it very much. I certainly agree that patch 116036 is clearer even though there's more disruption and more to read. I will be committing this same patch to trunk and, if it proves stable, to the 2.24 branch as a bugfix. I hadn't seen "Coding without comments". Thanks for pointing it out-- it was a good read, and something for everyone to keep in mind in writing and refactoring the rest of the code. Minor nitpicks: * I might have considered making (force_)save_user_window_placement() one function with an extra boolean parameter, but since actual parameters can't be named in C, that goes against the coding without comments idea. * "Only if the window is not maximized or fullscreen": I've modified this to "neither maximised nor fullscreen", since it made me go to read the code to check which way you meant it.
In trunk now: http://svn.gnome.org/viewvc/metacity?rev=3816&view=rev Closing.
By the way, thank you for the excellent work you've put into producing a carefully thought out and well-executed patch.
I am still experiencing this issue after upgrading from Hardy (8.04) to Intrepid (8.10) using metacity 2.24.0.
I am also still experiencing this problem with metacity 2.24.0 on Intrepid 8.10 (Note that I'm still using version 173 of the Nvidia driver due to a problem with screen resolution on xscreen 1 with the new driver). A summary of the behaviour I'm experiencing: Application launched from top panel in xscreen 1 opens in xscreen 0 - bad Application launched by association with a file-type in nautilus opens in the other screen - bad Launching using the console or Alt-F2 opens app on same screen - good Nautilus started from places menu starts on other screen - bad Nautilus started from link on desktop starts on same screen - good VLC and Flash fullscreen mode does stay on the same screen - good I've posted this info to the ubuntu bug downstream but thought it might be better here. Please let me know if there's any way I can help further. Thanks.
Well umm I'm also having trouble with this, and umm it doesn't make any sense but changing this line seemed to fix the problem: Forcing window->force_save_user_rect to TRUE... yeah, I don't know why this fixes it. Seems very counterintuitive, because it looks like the old patch tries to set this to FALSE when maximizing/fullscreening occurs, but it must be at the wrong time. Or maybe it's negating some other patch or something. I don't know. (MATE Desktop...similar file for GNOME 2.x) marco-1.4.0/src/core/window.c void meta_window_maximize_internal (MetaWindow *window, MetaMaximizeFlags directions, MetaRectangle *saved_rect) { /* At least one of the two directions ought to be set */ gboolean maximize_horizontally, maximize_vertically; maximize_horizontally = directions & META_MAXIMIZE_HORIZONTAL; maximize_vertically = directions & META_MAXIMIZE_VERTICAL; g_assert (maximize_horizontally || maximize_vertically); meta_topic (META_DEBUG_WINDOW_OPS, "Maximizing %s%s\n", window->desc, maximize_horizontally && maximize_vertically ? "" : maximize_horizontally ? " horizontally" : maximize_vertically ? " vertically" : "BUGGGGG"); if (saved_rect != NULL) window->saved_rect = *saved_rect; else meta_window_save_rect (window); window->maximized_horizontally = window->maximized_horizontally || maximize_horizontally; window->maximized_vertically = window->maximized_vertically || maximize_vertically; /*** HERE ***/ window->force_save_user_rect = TRUE; /* somehow fixes the issue? */ /*** HERE ***/ /* Fix for #336850: If the frame shape isn't reapplied, it is * possible that the frame will retains its rounded corners. That * happens if the client's size when maximized equals the unmaximized * size. */ if (window->frame) window->frame->need_reapply_frame_shape = TRUE; recalc_window_features (window); set_net_wm_state (window); } ------------------------ Ever since then I haven't had a problem. Then again, I'm not 100% sure what the code does in the first place, but everything seems to work fine to me.