Clicking on semi-maximized windows in a different workspace fails to switch to the correct workspace

[Barneedhar]

Steps to reproduce:
--------------------------
0. make sure there is no terminal window open.
1. Open a terminal window.
2. Move it to the top right workspace and snap it to the right edge of the screen
3. Go to workspace (1, 1) (top left) and click on the terminal icon in the launcher

What happens:
--------------------
Part of the window will now appear in the left side in top left workspace.

Expected:
--------------
When clicked on the window icon, the focus should move to the window and the workspace.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: unity 6.2.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.5.0-9.9-generic 3.5.0
Uname: Linux 3.5.0-9-generic x86_64
ApportVersion: 2.4-0ubuntu6
Architecture: amd64
Date: Wed Aug 15 23:31:16 2012
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
SourcePackage: unity
UpgradeStatus: Upgraded to quantal on 2012-07-10 (36 days ago)

[Launchpad Janitor (janitor)]

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

[Daniel van Vugt (vanvugt)]

Sounds like bug 755842, but it looks like you should have the fix for that in your version of compiz already.

[Marc Deslauriers (mdeslaur)]

I can confirm this, the fix in 755842 didn't completely resolve the issue.

[snowguy (snowguy)]

To clarify, in step 3 the clicking on the snapped window means clicking on the icon for snapped window in the unity launcher.

[Cavia Porcellus (caviaporcellus)]

Same problem that's been around since Natty; this is also still broken for non-snapped windows that rest on certain borders. E.g. if a window rests on the bottom border of the lower left workspace, then that window is called via the launcher in the upper left workspace, it moves into the upper left's workspace instead of shifting the view to the lower one.

[Marc Deslauriers (mdeslaur)]

FYI, the patch located here doesn't solve this issue: https://launchpadlibrarian.net/89746102/fix-762335.patch

[Didier Roche-Tolomelli (didrocks)]

Not completely related to snapped only window, but rather if height of a window == height of the screen (minus decorator size and so on).

So on a setup with, 2 monitors (one above the other), the biggest one being on top.
1. Have a window whose height match the above rule ^ on the bottom monitor (so maximized, vertically semi-maximized or non maximized window but manually making the size fitting that).
2. switch ws
-> the window jumps on the 1st monitor.

[Daniel van Vugt (vanvugt)]

Sounds like the problem might be bug 986051, which is then triggering bug 751605 putting it on the wrong monitor. A fix for either bug should be enough to avoid the problem.

Also possibly related/duplicates: bug 769672, bug 776435.

[Marc Deslauriers (mdeslaur)]

FYI, I am seeing this with a default sized terminal, it has nothing to do with the fact that a window is semi-maximized or not.

[Marc Deslauriers (mdeslaur)]

Also, it happens even if the window isn't snapped. As long as it's within a few pixels of the edge of the rightmost workspace, the issue presents itself.

[Esokrates (esokrarkose)]

If the window is placed in the upper right corner (<Control><Alt>KP9) or in bottom right corner (<Control><Alt>KP3) the behaviour is also wrong but different: Now the window keeps it's position but moves to the workspace it was accessed from:
For example place a window on the upper right workspace in the upper right corner and change to the upper left workspace. Now click the icon in the launcher and the window is dragged completely in the current (upper left) workspace.
To conclude, all the transitions concerning accessing a window that is placed on a workspace right to the current workspace do not work. All the transitions for accessing a window in a workspace left to the current workspace work. Only right and left matters, the height does not matter (meaning it does not matter if it is the upper right workspace or the bottom right workspace, only right matters).

[Esokrates (esokrarkose)]

http://ubuntuone.com/2JBSfSD69fTrjLzQWmNgoe

If the window is placed in a corner and I use the workspace switcher in the launcher, the window gets placed on the workspace I switch to, as shown in the video. However, if I switch by shortcut, and then access the window with the launcher, the window gets moved to the workspace it was accessed from, so the behavior is not exactly the same as for the semi maximized windows.
I noticed, that the bug also works for "up and down", but only in a special case as shown in the video: if I open the application an semimaximize it, the bug does not work, but if I close the application and reopen it, it has the same position and I access it from the upper workspace the same behaviour is shown, as for the right left issue. (Note: the window has to have exactly the same size after reopening, otherwise the bug does not seem to appear. You cannot reproduce it with a terminal window)

[Sam Spilsbury (smspillaz)]

Not specifically a problem with the experimental ppa

[Daniel van Vugt (vanvugt)]

Fix committed into lp:compiz at revision 3542, scheduled for release in Compiz 0.9.9.0

[Marc Deslauriers (mdeslaur)]

I confirm that backporting r3542 to quantal's compiz has resolved the issue for me.

[Matthieu Baerts (matttbe)]

It seems that I no longer have the bug #1096471 with this rev 3542 (If a window is moved next to the border of the screen on another viewport, sometime Compiz doesn't switch to the right viewport when we want to 'activate' this window).

@Sam: Thank you for this fix ;)

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.9~daily13.01.14-0ubuntu1

---------------
compiz (1:0.9.9~daily13.01.14-0ubuntu1) raring; urgency=low

  [ sampo555 ]
  * compiz crashed with SIGSEGV in DodgeAnim::applyDodgeTransform() (LP:
    #1048840)
  * compiz crashing if window un-/minimize animation is "Random" (LP:
    #1098185)

  [ Daniel van Vugt ]
  * Several leaks in new GLProgram from compileProgram() from
    GLScreen::getProgram() from GLWindowAutoProgram::getProgram() (LP:
    #1097644)

  [ Sam Spilsbury ]
  * Several leaks in ccsIntegratedSettingListAppend() ... from
    ccsGNOMEIntegrationBackendGetIntegratedSetting() from readSetting
    (gsettings.c:375) (LP: #1097661)

  [ MC Return ]
  * Thumbnail Window Previews: Flickering of background/glow and window
    title text (LP: #1098758)

  [ Automatic PS uploader ]
  * Automatic snapshot from revision 3561
 -- Automatic PS uploader <email address hidden> Mon, 14 Jan 2013 04:03:09 +0000

[Christo Apostolov (hr-apostolov)]

I can reproduce that on 13.04 64bit with compiz 1:0.9.9~daily13.04.18.1~13.04-0ubuntu1

This bug is present from the very beginning of Unity and have never been properly fixed despite the various reports and hundreds affected users.
Ant it is, IT REALLY IS, a bit usability issue!
It seems like nobody at Canonical cares enough... despite the many words said on "how important quality is"!

My guess is, that we'll have to live with it until they move to MIR and introduce one gazillion of other bugs... and the same $&/T comes all over again...

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release