When windows overlap workspaces, launcher doesn't properly switch windows.

[David Green]

If you have a window that is overlapping 2 workspaces and click on the launcher item for that window, the window is focused but not fully switched to. This is mainly a problem where the window overlaps only slightly and you are in the workspace that has the smaller portion of the window. A better behaviour would be to switch to the workspace that has the greater potion of the window in it.

[tankdriver (stoneraider-deactivatedaccount)]

Please take a look at this Bug #755842 (Non-maximized windows which sit on the border of a workspace move when called)
This could be the cause that the windows are overlapping, even when the user did not want it.

[Gerhard Burger (burger.ga)]

a special case of this is probably https://bugs.launchpad.net/unity/+bug/776074 where windows are pushed against the edges by using the snap feature

[Gerhard Burger (burger.ga)]

Maybe this bug should get a higher priority since its probably linked to 2 other bugs, and quite a show stopper

[Gerhard Burger (burger.ga)]

Correction, I think https://bugs.launchpad.net/unity/+bug/776074 I mentioned above is a duplicate of https://bugs.launchpad.net/unity/+bug/766339

[Stephen Rees-Carter (valorin)]

I believe this bug is related to Bug #755842, since both have the same trigger and the same result. The difference is, this one already has the window crossing the border while Bug #755842 only has the window border/shadow crossing.

In both cases the workspace should switch to the one with the most of the window visible, rather than try and display the window in the current workspace - which results in it being shifted since only the border is visible.

[Omer Akram (om26er)]

Stephen Rees-Carter, I think we should keep them both separate for now. ;)

[Martina Utopia (martina-utopia)]

This bug probalby relates to the behaviour of Evolution when using the German translation. It is known that the german Evolution window is 4 pixels too broad for netbook screens (1024x600), so those 4 pixels are always on the neighbouring workspace. This results in the behaviour described above:

Workspace (WS) numbering:
1 2
3 4

When Evolution is maximised on WS 1 and I switch to an application on WS 2 and I want to switch back to Evolution, WS 1 (and Evolution) is not displayed. Instead, WS 2 stays focussed. Strangely, this is also true for applications run on WS 4 (i.e. diagonal from WS 1), but not for applications above or below WS 1 (in this case WS 3), where I *can* switch to Evolution using the launcher.

Also, when Evolution is minimised, I *can* access it by the launcher from *all* workspaces.

[William Ranvaud (wiranvaud)]

Windows should never overlap workspaces, I think this alone is a bug...

[computermacgyver (computermacgyver)]

I agree with William, is there any way to simply prevent windows from ever overlapping multiple workspaces. I can't seem to find a way to make this happen.

[Gabe Gorelick (gabegorelick)]

It's debatable whether you should always prevent windows from overlapping multiple workspaces, since with things like the edge switcher plugin you may want to overlap workspaces.

This bug is really a pain when the window isn't even visible to the user. It can be quite frustrating to select the window from the launcher and have nothing visible happen. You're stuck having to search all your workspaces for the window in question.