Non-maximized windows which sit on the border of a workspace move when called

[Stephen Rees-Carter]

[Impact]

Windows get forcefully moved fully to the current workspace when they are partially overlapping the workspace and then alt-tabbed to.

[Test Case]

TESTCASE 1:
1. Move a window to the far right workspace so that it overlaps the right side of the screen a little.
2. Switch to the far left workspace where you can see a little of the overlapping window.
3. Alt-Tab to the window.

Observed: Window jumps to being entirely on the far left workspace.
Expected: Window stays where it was.

TESTCASE 2:
1. Move a window to the far left workspace so that it overlaps the left side of the screen a little.
2. Switch to the far right workspace where you can see a little of the overlapping window.
3. Alt-Tab to the window.

Observed: Window jumps to being entirely on the far left workspace.
Expected: Window stays where it was.

[Regression Potential]

Wall plugin / overlapping window behavior on multiple workspaces in general.

---

ORIGINAL DESCRIPTION:
Binary package hint: unity

The bug works as follows:

1. Put a non-maximized window against the border of your workspace

2. Switch to the adjoining workspace

3. Select the window in Unity

Expected Behavior

   You are switched back to the workspace with the window

What actually happens

   You stay in the current workspace AND the window is shifted slightly into the current workspace
   Making it impossible to use without manually switching to the workspace and dragging the window back to where it was

Screenshoted instructions:

1) Put an application window hard against the side of your workspace without maximizing it
    Bottom right workspace: http://rc.id.au/f/images/1-window-move-bug.png
    (All workspaces: http://rc.id.au/f/images/2-window-move-bug.png)

2) Go to a different workspace which shares an edge with your application
    Top right workspace: http://rc.id.au/f/images/3-window-move-bug.png

3) Click on the application within the launcher, and the application will jump a little way into the next workspace
    Top right workspace after clicking on XChat and Gwibber launcher icons: http://rc.id.au/f/images/4-window-move-bug.png

To show this more, I reset the windows to their original locations from #1, went into the bottom left workspace and clicked on Gwibber again: http://rc.id.au/f/images/5-window-move-bug.png

I hope that makes sense and explains the bug.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity 3.8.4-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-8.41-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,unitymtgrabhandles,scale,session,unityshell]
CompositorRunning: compiz
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Sun Apr 10 07:38:31 2011
DistUpgraded: Log time: 2011-03-24 19:34:20.948953
DistroCodename: natty
DistroVariant: ubuntu
DkmsStatus: vboxhost, 4.0.4, 2.6.38-8-generic, x86_64: installed
EcryptfsInUse: Yes
GraphicsCard:
 nVidia Corporation NV43 [GeForce 6600 GT] [10de:0140] (rev a2) (prog-if 00 [VGA controller])
   Subsystem: LeadTek Research Inc. Device [107d:2009]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110302)
InstallationMedia_: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110302)
InstallationMedia__: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110302)
ProcEnviron:
 LANGUAGE=en_AU:en
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-8-generic root=UUID=ed596b92-82a9-404c-ab2a-0cbc73a2e563 ro quiet splash vt.handoff=7
ProcVersionSignature_: Ubuntu 2.6.38-8.41-generic 2.6.38.2
ProcVersionSignature__: Ubuntu 2.6.38-8.41-generic 2.6.38.2
Renderer: Unknown
SourcePackage: unity
UpgradeStatus: Upgraded to natty on 2011-03-24 (16 days ago)
dmi.bios.date: 12/28/2004
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F6
dmi.board.name: NF-CK804
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF6:bd12/28/2004:svn:pn:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnNF-CK804:rvrx.x:cvn:ct3:cvr:
version.compiz: compiz 1:0.9.4+bzr20110407-0ubuntu2
version.ia32-libs: ia32-libs 20090808ubuntu11
version.libdrm2: libdrm2 2.4.23-1ubuntu6
version.libgl1-mesa-dri: libgl1-mesa-dri 7.10.1-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental 7.10.1-0ubuntu3
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+4ubuntu3
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu6
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu6

[Stephen Rees-Carter (valorin)]

I just managed to trigger this one for my Gwibber window in the Top-Left workspace - it pulled it diagonally into the workspace....

[tankdriver (stoneraider-deactivatedaccount)]

I usually work with lots of small windows, some of them sit on the border of the screen.
After a while, I thought the behavior of the unity launcher changes and when I click on an Icon, the workspace did not switch to the right one, or did not switch at all.
This bug is very annoying and definitely a big usability issue, especially for unity-newbies.

[tankdriver (stoneraider-deactivatedaccount)]

I just described Bug #738908 .

[ngc2997 (ngc2997-deactivatedaccount)]

In addition to the original report, I've seen very similar behaviour, but without the "moving" effect when clicking an application icon of an application on a different workspace - this had no other effect than blanking the upper panel, and the requested window's drop shadow became visible on the current workspace. As reported above, it did not switch workspaces as expected. I guess this might somehow be related to the original issue reported here, yet with a slight variation in its effect. Also, I've seen this happen with maximized windows (hardly reproducible though).

[Stephen Rees-Carter (valorin)]

This is really starting to get quite annoying. If I want to have two side-by-side windows, I can't simply use the Snap-to-Side feature, but I need to manually move the bottom and sides in from the edge...

[tankdriver (stoneraider-deactivatedaccount)]

I think this bug causes a strange behaviour of the launcher too:
- Do the steps to reproduce this bug (or work for some time with unity and mulitple programs ;-) ).
- Go to a workspace (which seems to be) without any open program windows.
--> The launcher hides for no noticeable reason.
Consequences: You think its an inconsistent behaviour of autohiding in the launcher. --> annoying.
Explanation: Due to the default 2x2 alignment of Workspaces in Unity, with this "wrap around feature" (I don't know the right name, but its the "when window overlaps the right border of the most right workspace, it appears on the left" thing) A window can "move" some pixels , from the left side coming, under the Launcher and it does autohide.

[Stephen Rees-Carter (valorin)]

Yep, I believe it's the same sort of issue.
Both are caused by the window shadow/border being detected as the edge of the window, so it is acting as if the window is wider & taller than it actually is.

In that case, it's auto-hiding the launcher as it's sitting under the launcher from a wrapped window.

I can see three solutions (none of which I know how to implemenent):
1) Disable window shadows/borders completely
2) Make the shadows/borders external to the window dimensions so they aren't taken into account like they currently are
3) Stop workspaces from wrapping directly into each other

[William Ranvaud (wiranvaud)]

I have described this also in askubuntu (asking for some suport)
http://askubuntu.com/questions/49901/window-is-invading-wrong-workspace-when-clicked-on-unity-launcher-icon

Very annoying

[Stephen Rees-Carter (valorin)]

This is also affecting Oneiric now...

[Alex Thompson (alexofdoom)]

In Oneiric this is mostly fixed for me. The only case where I can trigger a window move is when I have one near the bottom of the workspace in workspace 2 or 4 and call the window from workspace 1 or 3.

[Stephen Rees-Carter (valorin)]

I reported a separate bug for Oneiric a while ago... https://bugs.launchpad.net/unity/+bug/834248

But I guess they should be merged, since I assume they are the same bug. It would be nice if one of the developers acknowledged this as an issue... it feels like it's simply being completely ignored.

[Henryk Plötz (henryk-ploetzli)]

In Oneiric this is even worse due to the new Alt-Tab behaviour of including windows on all workspaces. I experience this mostly with vmware (since maximising the window and just dragging it so big that all sides touch the sides of the monitor are distinct things in vmware). Previously the shift only happened when clicking the vmware icon in the launcher. I could easily compensate that by putting the window on a dedicated workspace of its own and using workspace switching to get to and fro.

Now, when switching from the workspace with the problematic window to a different workspace, the window gets recorded into the alt-tab history, so the bug is triggered when next I hit alt-tab.

[Cavia Porcellus (caviaporcellus)]

I'm also affected (and frightened to find out that this bug has been around since Natty). I described my experience here: https://bugs.launchpad.net/unity/+bug/834248

I've found if you disable the Compiz window decorations the "snap-to-windows" function actually works great and you can switch windows with the launcher and alt-tab! Of course, window decorations are pretty nice to have, so it's a pretty useless workaround - if it can even be called that.

But at least it's clear that there's something wrong with the window decorations. My guess is the shadows, but they are impossible to turn completely off (as fare as I can tell), so I can't be sure.

[Yuriy Kulikov (yuriy-kulikov-87)]

This bug is very annoying when dock is used to switch between workspaces, which I, personally, use a lot.
Attached screenshot describes how to reproduce it. Hope it helps.

Cheers,
Yuriy

[dan (web-zzzzz)]

This is very annoying and i cant wait for it to be fixed.

[j-stuffer (j-stuffer)]

Seems it depends on which workspace you are and to which border the window is near.
Try the following:
1. Maximized Browser on upper left workspace
2. On upper right workspace: Put a Nautilus-window to the right side so it "sticks" to the right border (or is only few pixels away)
3. Go back to upper left workspace
4. Klick on Nautilus-symbol
5. Workspace does not switch to upper right and shows Nautilus. Instead I stay on upper left workspace and show a small part of Nautilus.

When putting Nautilus to the right side of the lower left workspace everything works fine. Putting Nautilus on lower right workspace it's messed up again.

Putting Nautilus next to the bottom (but not next to left/right edge) on upper right workspace works fine. But on both lower workspaced it's messed up again.

[Daniel van Vugt (vanvugt)]

Fix committed into lp:compiz-wall-plugin at revision 133

[Daniel van Vugt (vanvugt)]

Fix committed into lp:compiz-plugins-main at revision 32

[TomasHnyk (sup)]

Will this be SRUed?

[Daniel van Vugt (vanvugt)]

This bug is not a priority. I would not expect it to be SRU'd, but it's still possible. Also, only half the fix has been approved and committed so far...

[Dan Smith (dansmith)]

Seriously? The number of "regular" users that have asked me for help with this tells me that this is a serious usability issue. People often lose work because they don't understand that a window has gone off to be on workspace 4 and reboot to get the app to start again. Will users that want to stay on this LTS really have to live with this for two more years, or are these sorts of updates considered for 12.04.1?

[TomasHnyk (sup)]

vangut: understoo, but it would still be nice if it were, it pretty much kills the usability of grid plugin for me ( I seem to be unable to completely stop using launcher for applicatin switching)

[j-stuffer (j-stuffer)]

I don't understand why this hasn't been fixed, yet. It's a serious usability issue. You can't use the switcher to switch programms, which from my experience most of the people will do. At the beginning I thought the window had disappeared and it took me some time to figure out, that it only went to another workspace. Also when it's on another workspace, you can't always move it because the menu of the window is on a different workspace. Where is the point having different workspaces in the first place when you can't use them properly? I love the concept of different workspaces but at the moment I think it's better to have everything on one workspace because then it does not get messed up.

[Victor Zamanian (victorz)]

I agree. This is one of many bugs that have been lingering with Unity for a long time that make Unity feel like beta software. It's also one of the reasons why I stopped using it and have started using GNOME Shell instead. And because I don't use the default Desktop Environment, i.e. Unity is just sitting there installed on the harddrive without me ever using it, I almost feel like I should just switch to Arch or something where I can pick GNOME Shell right off the bat. (I know I can probably uninstall Unity on Ubuntu too, but... you know. :P)

So, as you can see a few seemingly small bugs can cause a chain of reactions/decisions (as in my case) to where I'm actually considering switching distro altogether. I think that's sad, because I like Ubuntu, its community and resources. Just not Unity.

[Justin Force (justin-force)]

I agree. Any serious usability bug is going to taint people's experience of Unity and Ubuntu. When Unity feels broken, Ubuntu feels broken. People don't care about the process for SRU approval or the root cause of a usability bug; they care about using their programs. Bugs in Unity make me hesitant to recommend Ubuntu to non-computer savvy people, and Ubuntu is really meant for exactly those people.

[Daniel van Vugt (vanvugt)]

I did not mean to say this bug is not important enough to be fixed. Just that we are all very busy and lots of important bugs are likely to not get some attention for quite some time. Hence "I would not expect it to be SRU'd, but it's still possible".

[Daniel van Vugt (vanvugt)]

Fix committed to lp:compiz/0.9.8 at revision 3152.

[Tyler Wagner (tyler)]

If it won't be SRU'd, does anyone have a PPA to fix it? We're installing precise company-wide, and we cannot continue with the present behaviour. It's a huge issue for us.

[Marc Deslauriers (mdeslaur)]

This definitely needs to be SRUed into the LTS release.

[Marc Deslauriers (mdeslaur)]

FYI, I can still trivially reproduce this annoying issue with an up-to-date quantal.

[Daniel van Vugt (vanvugt)]

Marc,

Yes it seems either this fix is missing in quantal or it wasn't fully fixed. The regression is being tracked as bug 1037164. Please comment there.

[Tyler Wagner (tyler)]

I am hugely disappointed that this was tagged to milestone 12.04.1 but is not fixed today.

Please bump importance to High and make this a priority. This is far more damaging to usability than bug #933776.

[Dan Smith (dansmith)]

Does the milestone update mean that this is not fixed in 12.04.1? I'm still seeing it, but was hoping that package updates are still filtering out.

[Jacob Williams (jacobw.me)]

The fix for this bug in compiz being released with milestone 0.9.8.0 is good news, although it's not obvious how this will resolve the issue for users of 12.04.

* Will compiz milestone 0.9.8.0 be released with ubuntu milestone ubuntu-12.04.2?

* Will compiz milestone 0.9.8.0 be pushed to precise-updates, precise-proposed or precise-backports before the release of ubuntu-12.04.2?

* This bug is affects compiz-wall-plugin and compiz-plugins-main which both have fixes commited, does the fix for this issue require patches to all 3 packages?

* When the fixes are released for compiz-wall-plugin and compiz-plugins-main, will they be pushed to precise-proposed or precise-backports before the release of ubuntu-12.04.2?

It seems to me that the developers of these packages are coordinating to release fixes to their packages for the next SRU, 12.04.2; however, prior to the release of 12.04.1 it seems that the developers where coordinating to release the fixes for 12.04.1.

I can't speak for the 100 other people affected by this bug but following the release of 12.04.1, I would appreciate an update on how these fixes are being released, and when we can expect this issue to be resolved for users of 12.04.

[Timo Jyrinki (timo-jyrinki)]

Jacob: Since this fix is targeted to 12.04 as well, the commit fixing this particular problem should be pushed to the 0.9.7 branch (https://code.launchpad.net/~compiz-team/compiz-core/0.9.7), from which the Ubuntu 12.04 LTS compiz releases are made. The first compiz SRU (stable release upgrade) deployed to the masses two weeks ago contained similar backported fixes already, so this would be something targeted for the next SRU.

The 12.04.2 is the name of the next "whole Ubuntu" SRU, but it only acts as a high level target and compiz SRU itself may come earlier. The point releases are simply updated install images, while the actual fixes they contain come to existing users over time, before the point release. The reason for this bug fix not making it to the original 12.04.1 schedule is simply that it was only now fixed in the development 0.9.8 branch, as indicated, and before deploying to tens of millions of people the fix will need proper preparing, testing etc. in combination with the 12.04 stack. It's not always so that the backported fix would behave exactly like it does in the development version, since 0.9.8 branch has seen significant re-working of compiz code in many places compared to 0.9.7.

Any package SRU:s will first appear in precise-proposed, and then if no problems are reported in this final test phase it will finally released into precise-updates.

[Jacob Williams (jacobw.me)]

Thanks for taking to time to clarify the process and explain what's going to happen, it's much appreciated.

I'll make sure to test these packages as they arrive in precise-proposed and update this bug.

[Daniel van Vugt (vanvugt)]

This bug was fixed in the package compiz - 1:0.9.8.0-0ubuntu1

---------------
compiz (1:0.9.8.0-0ubuntu1) quantal-proposed; urgency=low

  * debian/control, debian/rules:
    - enable gles on armel and armhf
    - use dh-translations rather than custom code

  [ Sam Spilsbury ]
  * Enable OpenGL ES building
    - Refresh debian/patches/workaround_broken_drivers.patch
    - Remove non-ported plugins from compiz-plugins
    - Add FindOpenGLES2.cmake to compiz-dev

  [ Timo Jyrinki ]
  * New upstream release.
    - Code to make compiz work on GLES. This includes several changes
      to the compiz API. (LP: #201342) (LP: #901097) (LP: #1004251)
      (LP: #1037710)
    - Draft first 0.9.8.0 NEWS and bump VERSION
  * debian/patches/compiz-package-gles2.patch:
    - Remove, obsoleted by the upstream GLES work
  * Disable plugins that don't work on pure GLES on armhf/armel:
    - bench, firepaint, mblur, showmouse, splash, showrepaint, td, widget
 -- Sebastien Bacher <email address hidden> Fri, 31 Aug 2012 22:59:50 +0200

[Tyler Wagner (tyler)]

Hi Daniel,

Your last comment lists "no longer affects: compiz (Ubuntu Precise)". However, an updated package doesn't yet exist in precise-proposed or the standard repositories. Do I misunderstand?

Should we test compiz from Quantal on Precise, or is there a better solution for those of us trying to use an LTS release? I'm trying to suppose this internally for an organisation depending on Precise.

[Daniel van Vugt (vanvugt)]

Tyler,

I was removing an invalid entry there. This fix for precise is still queued.

For precise, the fix for this bug is in lp:compiz-plugins-main and will be available in compiz-plugins-main 0.9.7.4:
   https://launchpad.net/compiz-plugins-main/+milestone/0.9.7.4
Sorry, but no estimate on when that will be. To add to the confusion, Ubuntu packaging then moves the wall plugin into package "compiz-plugins-main-default" which has a different version again. And Ubuntu frequently pulls fixes like this before they're officially marked as released upstream.

To know when this bug is fixed in precise, you should look at the top of this bug at:
  compiz-plugins-main (Ubuntu) > Precise

[Marc Deslauriers (mdeslaur)]

I can still trivially reproduce this with compiz 1:0.9.8.0-0ubuntu1 and an up-to-date Quantal install on a Thinkpad T61. Reopening.

[Cavia Porcellus (caviaporcellus)]

Apologies if I'm missing something, but I just tested this out on an up-to-date Quantal, and it is still very broken.

[Alexis Wilke (alexis-m2osw)]

I'm not too sure what you mean by "fixed" but for me this still doesn't work at all.

What I really need is a flag in the compiz settings to nicely ask the compiz system to NEVER move my windows. If I put it in the wrong place, that's very much my problem, not compiz problem.

If such a flag already exists, I'd really appreciate for someone to speak up about its location.

For sure, in 12.04 kept up to date server that I have it doesn't work as I would expect. The problem is not just the shadows on the edges, it's the whole window moving just because the focus goes to another window. That's just not useable in this way. If I just moved a window out of the way, why is my windowing system putting it right back where I did not want it?!

[Daniel van Vugt (vanvugt)]

All,

To avoid confusion, if you still have problems after you have this fix (in Ubuntu 12.10), please log a new bug.

[Marc Deslauriers (mdeslaur)]

New bug is #1037164

[Cavia Porcellus (caviaporcellus)]

Uh, do we still complain about it here for Precise? I guess this isn't "fixed" there yet, but since the "fix" in Quantal changed nothing at all, I'm not very hopeful for the Precise "fix."

[androith (androith)]

The confusion here might be the result of poor testing which in turn arose due to too many bug reports.

This bug report doesn't clearly describe how I (and others!) reported this issue because too many slightly differing bug reports got merged. To the developers/testers:

1) Open nautilus.
2) Move it to the second workspace.
3) Snap to the right half of the screen.
4) Go back to the first workspace.
5) CLICK the nautilus icon. (No alt-tab nonsense.)

If the nautilus window moves to the third workspace (or around there), the bug isn't fixed.

[j-stuffer (j-stuffer)]

For me the Bug is still existing in 12.10 as well as in 12.04 and I can reproduce it every time with the steps androith mentioned above (second workspace = the workspace on the upper right!). Should I or someone else make a video to make it more clearly how the bug is triggered?

[Ricky Brent (rickybrent)]

Is there any workaround for this besides using another window manager? I am rather liking Unity but this makes the launcher nearly useless.

[arnuschky (abrutschy)]

Can confirm still present on up2date 12.04.1 (compiz 1:0.9.7.8-0ubuntu1.4).

[Jorge Suárez de Lis (ys)]

I can still reproduce this on 12.04 and 12.10. Maybe the fix is actually not released on 12.10? or is not working as expected?

Also, bug #1037164 is a completely different behaviour. I'm mostly worried about THIS bug, not the other one.

[Daniel van Vugt (vanvugt)]

Jorge,

This bug is marked as fix released in Compiz 0.9.8.0. So it should be fixed in 12.10 and later. If it's not then please log a new bug.

[Stepan Roucka (rouckas)]

I can also still reproduce this bug on up-to-date Quantal (compiz 0.9.8.4+bzr3407-0ubuntu1) upgraded from Precise. Is there something more needed to fix it? Like clearing some configuration?

[Daniel van Vugt (vanvugt)]

Stepan,

According to comment #38 you have the fix for this bug already. If you have compiz 0.9.8.4 and still have problems then please log a new bug using this command:
    ubuntu-bug compiz

[Esokrates (esokrarkose)]

I know you say the bug is fixed and we should open a new bug report, but the issue remains for Compiz version 0.9.9 with exactly the same behavior (But it is indeed partly fixed). Does it really make sense to open a new bug report describing exactly the same issue?
This part of the description is fixed:

"
TESTCASE 1:
1. Move a window to the far right workspace so that it overlaps the right side of the screen a little.
2. Switch to the far left workspace where you can see a little of the overlapping window.
3. Alt-Tab to the window.

Observed: Window jumps to being entirely on the far left workspace.
Expected: Window stays where it was.

TESTCASE 2:
1. Move a window to the far left workspace so that it overlaps the left side of the screen a little.
2. Switch to the far right workspace where you can see a little of the overlapping window.
3. Alt-Tab to the window.

Observed: Window jumps to being entirely on the far left workspace.
Expected: Window stays where it was.
"

This part of the issue is NOT fixed:

"
1. Put a non-maximized window against the border of your workspace

2. Switch to the adjoining workspace

3. Select the window in Unity

Expected Behavior

   You are switched back to the workspace with the window

What actually happens

   You stay in the current workspace AND the window is shifted slightly into the current workspace
"

I can only confirm that the issue is definitely not fixed on the latest compiz builds (both latest offical Compiz 0.9.9 and Compiz Experimental PPA) .

Daniel, should I open a new bug describing the part which is not fixed?

[Esokrates (esokrarkose)]

Oh there is already a bug report : https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1037164
It is not marked fixed and exactly describes the part of the issue which has been left.

[androith (androith)]

Got moved to 12.04.3. Well, that's disappointing. Is there a donation amount that would expedite the resolution of this bug?

[Timo Jyrinki (timo-jyrinki)]

There is a test package for Ubuntu 12.04 LTS available in ppa:unity-team/sru - compiz-plugins-main (& -default) 1:0.9.7.0~bzr19-0ubuntu10.1~test1

I briefly tested it seems to fix the test cases 1 & 2 for me, ie. the part that the window now stays where it is instead of moving. If there are no regressions, we can move towards getting this SRUed to 12.04 as it improves the situation and additional bug(s) has been filed for the remaining issue(s).

[Steve Langasek (vorlon)]

Hello Stephen, or anyone else affected,

Accepted compiz-plugins-main into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/compiz-plugins-main/1:0.9.7.0~bzr19-0ubuntu10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[TomasHnyk (sup)]

Is thi for raring or precise??

[Achim (ach1m)]

It is for Precise.

[Timo Jyrinki (timo-jyrinki)]

It should be already fixed for raring. Now it would be nice to get a verification on the precise-proposed version.

Note that the fix is only for the test cases 1 & 2 as now indicated in the top part of the current description, and eg. the bug #1037164 still remains unfixed so it's not in this scope of this update.

[Jani Uusitalo (uusijani)]

Verifying that for both test cases the issue is no longer reproducible with the proposed packages. In other words, results with packages from -proposed are as described in "Expected:" for each test case. (For both cases the issue was reproducible here with 1:0.9.7.0~bzr19-0ubuntu10.)

jani@saegusa:~$ LC_ALL=C apt-cache policy compiz-plugins-main compiz-plugins-main-default
compiz-plugins-main:
  Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
  Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
  Version table:
 *** 1:0.9.7.0~bzr19-0ubuntu10.1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1:0.9.7.0~bzr19-0ubuntu10 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
compiz-plugins-main-default:
  Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
  Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
  Version table:
 *** 1:0.9.7.0~bzr19-0ubuntu10.1 0
        500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1:0.9.7.0~bzr19-0ubuntu10 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

[Colin Watson (cjwatson)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz-plugins-main - 1:0.9.7.0~bzr19-0ubuntu10.1

---------------
compiz-plugins-main (1:0.9.7.0~bzr19-0ubuntu10.1) precise; urgency=low

  * debian/patches/fix_755842.patch:
    Fix non-maximized windows which sit on the border of a workspace move
    when called (LP: #755842)
  * debian/patches/fix_1015151.patch:
    Fix a crash related to the above fix (LP: #1015151)
 -- Timo Jyrinki <email address hidden> Mon, 25 Feb 2013 10:56:33 +0200

[zzarko (zzarko-gmail)]

Not working for me, so I filled a new bug repport (bug #1201714), as suggested.