Drag down from panel to restore does not instantly lock window position relative to mouse cursor.

[Dan Lea]

Ubuntu 11.04, Unity 3.8.16-0ubuntu1~natty1.

A nice feature of unity when using two monitors with TwinView is the ability to pull down a maximised window (restore) from one screen and drag it to the top of the other to maximise it there. This feels very natural and lends itself to a swift movement. It seems that the intention for a drag down is that the restored window be positioned such that the mouse cursor is at the top and middle of the window's title bar, as is the case it the action is performed very slowly. When the action is performed swiftly, there is an offset from this position, as if some initial part of the mouse displacement is excluded. This means the mouse cursor ends up lower down in the window, and for a swift manouevre from the left screen to the right for example, the window also ends up behind its intended position (i.e. centred left of the mouse cursor). While this does not prevent the user from maximising the window on another screen (and so does not constitute of a loss of functionality), it is a real detriment to the ergonomics of the operation, which I would say ranks it slightly above a purely cosmetic bug.

[Marco Trevisan (Treviño) (3v1n0)]

Unfortunately at the current status to make this work in unity has been used a workaround which uses X raw calls to move a window. So apparently it seems that the compiz grid plugin (which is charge to restore a window) waits a too much time before restoring the moved window.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alex Baggott (alex-baggott)]

Sorry folks, but, as part of the bug clean up ahead of 16.04 LTS, I'm marking this as invalid because it affects an Ubuntu release which is now unsupported. If you can still recreate this bug in a supported release, please do open a new bug and we can triage it for consideration in the 16.04 LTS development cycle.