window dimensions are not consistent between get_outer_rect and move_resize_frame

[Tim Cuthbertson]

If you have at least one non-maximized window open, and run the following script (just paste it into looking glass) you should see a window get smaller, despite the fact that the code should be a no-op. It is reading the current bounds of the window + frame (via get_outer_rect), and then assigning them back (via move_resize_frame):

(function() {
 var log = global.log;
 var resize_noop = function(w) {
  log("resizing window " + w.get_title());
  var r = w.get_outer_rect();
  log("resizing to existing size: " + r.width + "x" + r.height + " @ " + r.x + "," + r.y);
  w.move_resize_frame(true, r.x, r.y, r.width, r.height);
  r = w.get_outer_rect();
  log("and now it is: " + r.width + "x" + r.height + " @ " + r.x + "," + r.y);
 };

 var ws = global.screen.get_workspace_by_index(global.screen.get_active_workspace_index());
 log("ws = "+ ws);
 var windows = ws.list_windows();
 var win = windows[0];
 log("win = " + win);
 resize_noop(win);
})();

For background, this behaviour is causing windows to shrink over time in `shellshape` (http://gfxmonk.net/shellshape/), which I develop.

I *think* the bug may be related to the gtk3 theme padding / shadow properties specific to ubuntu, as the same code worked fine in fedora 15 (although that was gnome-shell 3.0.1, so it could also be a 3.2 change).

For reference, here is the log output I get. Note that the window dimensions do indeed shrink after the call to move_resize_frame:

      JS LOG: ws = [object instance proxy GIName:Meta.Workspace jsobj@0x7ff79bc60510 native@0x9cb4e0]
      JS LOG: win = [object instance proxy GIName:Meta.Window jsobj@0x7ff79a0e11b0 native@0x142d5f0]
      JS LOG: resizing window tim (/home)
      JS LOG: resizing to existing size: 1898x1115 @ 0,26
      JS LOG: and now it is: 1880x1097 @ 9,34

Ubuntu oneiric, using gnome-shell obviously. mutter package version 3.2.1-0ubuntu2

[Tim Cuthbertson (gfxmonk)]

damn. just realised meta_window_move_resize_frame was a function I added, and I'm not running the vanilla binary like I thought. So this bug is invalid until I can reproduce it with normal mutter...