GNOME Bugzilla – Bug 651012
When entering overview first time, windows mispositined, close button clipped
Last modified: 2013-06-14 16:35:29 UTC
Restart shell Have four windows Move pointer to upper right quadrant of screen Trigger overview from keyboard If necessary, move pointer out of and back into the upper right window Close button appears partially clipped Jasper pointed out on IRC that the problem is that the windows are sized and positioned differently on the first enter into the overview, and space isn't left around the edges, so the close button is clipped to the workspace boundaries.
Created attachment 188530 [details] [review] workspace: reposition widnows on workspace resize initial window position was broken (part of close button was clipped)
*** Bug 652076 has been marked as a duplicate of this bug. ***
Comment on attachment 188530 [details] [review] workspace: reposition widnows on workspace resize makes sense, fixes the bug
(In reply to comment #3) > (From update of attachment 188530 [details] [review]) > makes sense, fixes the bug I agree that it makes sense, but I'm a bit wary of calling positionWindows() repeatedly for the same animation with different flags (not passing INITIAL in the 2nd invocation works, as it does not affect the scaling properties, but that seems a bit coincidental). For what it's worth, I've digged into it a little, and the reason for the misplacement is an allocation change of WorkspacesDisplay.actor *after* the overview has been shown (mostly due to delayed style changes). Calling this._group.ensure_style(); this.viewSelector.actor.ensure_style(); in Overview.init() reduces the allocation change significantly (4px on my machine). So far I've been unable to determine what triggers the remaining allocation change - it appears to have some other reason than a style change.
I can't reproduce this in 3.8 (not surprising considering that the layout code has been rewritten completely since 3.0)