Window management - When a semi-maximised a window is maximised and then restored, the window position jumps and window size changes so the the window title bar is sometimes hidden underneath the top bar

Bug Description

Note: reverting bug to triarged because the fix is not complete. When tested the correct behavour of "the window should return to exactly the same state it had at the beginning of step 1." is not fulfilled.

-----------------------------------

Window management - When a Semi-maximising a window is maximised by clicking on the window decorations and then returned to the semi-maximised state, the window position jumps so the the window title bar is hidden underneath the top bar.

One way reproduce the bug:
1. Take a restored window
2. Semi-maximise the window
3. Press CTRL + SUPER + UP ARROW to maximise the window
4. Click on the 'restore' window decoration to return the window to the restored state state.

What currently incorrectly happens:
- After performing step 3, the window returns to a weird state where it is restored, but in the size and shape of a semi-maximised window, and the position is also offset from what would be expected from a semi-maximised window. This is especially problematic because in some cases the window is positioned so that all of the window title bar is underneath the top bar, making it impossible for a user to move the window without knowing a keyboard shortcut.

See the attached screencast "window_positioning_issue.ogv" to see the bug in action. (In the screencast this bug is reproduced using the window decorations instead of the Alt+F10 shortcut, which won't be possible after bug https://bugs.launchpad.net/ayatana-design/+bug/796594 is fixed)

Desired behavour:
- On pressing the 'restore' window decoration in step 4 of the bug reproduction instructions, the window should return to exactly the same state it had at the beginning of step 1.
- When fixing this bug, also review and look at fixing bug https://bugs.launchpad.net/ayatana-design/+bug/796594 as these issues are related

-------------------------------------------

Another way to reproduce the bug:
1. Semi-maximise the Thunderbird main window
2. Press the 'restore' window decoration (button on the far right of the 3 button cluster)

What currently incorrectly happens:
- The window jumps up so that the window title bar in underneath the top bar

What should happen
- The window should return to it's previous 'restored' state.

- Window management - When a Semi-maximising a window is maximised by- clicking on the window decorations and then returned to the semi-- maximised state, the window position jumps so the the window title bar- is hidden underneath the top bar+ Window management - When a Semi-maximising a window is maximised and+ then restored, the window position jumps and window size changes so the+ the window title bar is sometimes hidden underneath the top bar

- Window management - When a Semi-maximising a window is maximised and+ Window management - When a semi-maximised a window is maximised and then restored, the window position jumps and window size changes so the the window title bar is sometimes hidden underneath the top bar

When one semi-maximises a window by dragging its title bar to the right and then tries to restore it by dragging its title bar away from the top, the window also jumps quite far away from the cursor while still holding in the click. This behaviour is quite awkward. Was this also fixed in this commit?

[ Łukasz 'sil2100' Zemczak ]
* Remove debian/patches/unity_support_test.patch:
- Running the support test from compiz has bad side effects, from now
on we run it from Xsession.d
* Automatic snapshot from revision 3644

[ Nikolay Martynov ]
* When static switcher is enabled and has an option to show
application icon turned on the icons are expected to be ~1/3 of a
thumbnail (48px). Instead they are displayed in 512px size and
completely cover everything. This change addresses this issue. See
LP #1173914. (LP: #1173914, #1186426)

[ Brandon Schaefer ]
* Unrevert 3728, fix failing tests. Change the behaviour of
undecorating windows. Previously when a window was undecorated, we
would shift it back to an appropriate position according to its
gravity member. That behaviour was problematic because in the
StaticGravity case the window has to just stay in the same place.
But then if you had a window with StaticGravity which then did get a
decoration and later removed it, it would be placed as though it was
decorated and appear to be in the wrong place. The correct behaviour
is to place all windows as though they have decorations, and then
when decorations are removed, to move the window back to the corner
as indicated in its gravity and then expand its size to cover the
obscured regions no longer hidden because the decorations went away.
(LP: #1165343). 1. Completely remove decorOffsetMove and other
related code from decor.cpp. Put the logic to handle the
window->input () - window->border () placement offset inside of
setWindowFrameExtents instead. Now the window will always be
offset from its original non-decorated position to the new
decorated position, rather than having to guess between
decoration sizes. 2. Make saveGeometry and restoreGeometry work
relative to window->border () a...