GNOME Bugzilla – Bug 714707
A window is cut off at the top & buttom & side
Last modified: 2013-12-05 16:28:44 UTC
Created attachment 261120 [details] Screenshot - the nautilus is cut off The window of nautilus (whic is a client-side-decorated window), when the window is maximize is cut off at the top & button & side. See the screenshot.
Created attachment 261121 [details] Screenshot - gnome-terminal is cut off in the right side
This seems to be happening to some apps as well on build.gnome.org: http://build.gnome.org/continuous/buildmaster/builds/2013/11/21/58/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-gnome-tweak-tool.desktop.png
Created attachment 261236 [details] [review] window-props.c: React to changes to _GTK_FRAME_EXTENTS When _GTK_FRAME_EXTENTS changes, we need to redo constraints on the window - this matters in particular if the toolkit removes invisible borders when a window is maximized, since otherwise the maximized window will be positioned as if it still has invisible borders.
Review of attachment 261236 [details] [review]: Makes sense.
The obvious bad thing about this patch is that the sequence might be A) Mutter maximizes the window, picking a new size and setting the maximized state B) GTK+ changes the frame extents and redraws C) Mutter repositions the window D) GTK+ redraws again The only reason I can think of that this might *not* happen is that if in step B GTK+ makes a ConfigureRequest - then GTK+ will not freeze the frame clock and not redraw until the corresponding ConfigureNotify is received. But in most cases, I don't think that GTK+ will send the ConfigureRequest. Let me write a test case to see if the double redraw actually happens. If it does happen, then options: A) make GTK+ force sending a ConfigureRequest when it changes the frame extents to a new size. B) Change _GTK_FRAME_EXTENTS to allow listing multiple frame extents that are different when maximized/tiled. (Does GTK+ know in advance, or is it up to the app?) [In case A) though we avoid the double redraw, we do still annoyingly allocate a window pixmap of the wrong size.]
Created attachment 261237 [details] Test case showing that double redraw does happen Output when maximizing this test case: allocated to 1944x1198 allocated to 1944x1198 paint allocated to 1920x1173 allocated to 1920x1173 paint (I'm not offhand sure why double ::size-allocate signals occur in this case - I don't think it's related to anything Mutter is doing.)
Owen, thanks for the patch. The patch realy fixed the problem with the headerbar with nautilus, but not fixed the problem with gnome-terminal.
Created attachment 261456 [details] Screencast - more something wrong I see (with and without the patch above)
I also see this with Firefox and Qt apps, so it can't be only _GTK_FRAME_EXTENTS.
(In reply to comment #9) > I also see this with Firefox and Qt apps, so it can't be only > _GTK_FRAME_EXTENTS. See which? The behavior that Yosef is describing in comment 8?
Ah, no. For a split second, I see wrong frame behavior, with the content sticking outside of the frame, or the frame looking way too big for the content. Sometimes it seems to stick around for a second, but after that, it fixes itself. I don't see it all the time -- it's very, very occasional.
Unmaximizing a Firefox window by double-clicking on the title bar seems to consistently reproduce it.
Created attachment 263587 [details] [review] Use the correct frame size during unmaximize When unmaximizing, we changed bits of window state, then called out to code that used the frame extents *before* we cleared old cached extents. Clear the cache up-front as soon as we change the window state. ---- This patch fixes problems when unmaximizing gtk3-window-demo for me - hopefully it also fixes problems with firefox, gnome-terminal, etc, which I haven't reliably reproduced.
Comment on attachment 261236 [details] [review] window-props.c: React to changes to _GTK_FRAME_EXTENTS Attachment 261236 [details] pushed as ff790f7 - window-props.c: React to changes to _GTK_FRAME_EXTENTS
Review of attachment 263587 [details] [review]: OK.
Comment on attachment 263587 [details] [review] Use the correct frame size during unmaximize Patches pushed. Can you test, Yosef, to see if this fixes everything you see? Attachment 263587 [details] pushed as 3283018 - Use the correct frame size during unmaximize
I can to verify, the patches fixed all the issues in this bug, also the bug with a client-side-decorated window and also the bug with a non-client-side-decorated window. Thanks!