[With Patch]: Non-maximized windows which sit on the bottom edge of the lower workspaces shift downwards when called from an upper workspace.

[Stephen Rees-Carter]

This can be linked to another issue: when restoring a window, it's shifted down and does not come back to its former ratio. Please check the patch attached.
---------------
Non-maximized windows which sit on the bottom edge of the lower workspaces shift downwards when called from an upper workspace. This results in the bottom of the window wrapping into the top of the upper workspace, and the focus stays on the same workspace. The window is now unusable, and you need to manually move to the bottom workspace to move the window back up.

This is a big problem because it makes the "snap-to-side" feature completely useless. You have to drag the window to the side to half-screen it, and then drag the bottom border up slightly so it's got a margin between the border and the workspace edge so it doesn't move.

STEPS TO REPRODUCE:

1. Go to your BOTTOM RIGHT workspace

2. Open a window (i.e. Nautilus, etc)

3. Drag the window right to activate the "snap-to-side" feature and let it resize the window to full half the screen

4. Go to your TOP RIGHT workspace

5. Click on the window you opened in #2 icon in the launcher

6. The window you created in #2 will be moved 'down' so the bottom strip of it will appear in the top right of your current workspace

7. Go to your BOTTOM RIGHT workspace and you will see it's now sitting off the bottom of the workspace.

I previously reported this bug for Natty too: https://bugs.launchpad.net/unity/+bug/755842

Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,resize,fade,unitymtgrabhandles,scale,session,unityshell]
DistUpgraded: Log time: 2011-08-13 09:59:34.142096
DistroCodename: oneiric
DistroRelease: Ubuntu 11.10
DistroVariant: ubuntu
DkmsStatus:
 vboxhost, 4.1.2, 3.0.0-8-generic, x86_64: installed
 vboxhost, 4.1.2, 3.0.0-9-generic, x86_64: installed
EcryptfsInUse: Yes
GraphicsCard:
 Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21dd]
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110812)
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 003: ID 5986:03b4 Acer, Inc
MachineType: LENOVO 7859CTO
Package: unity 4.10.2-0ubuntu2
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_AU:en
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-9-generic root=UUID=2b5165d2-f495-4edb-8a9c-eb617417d459 ro quiet splash noapic vt.handoff=7
ProcVersionSignature: Ubuntu 3.0.0-9.14-generic 3.0.3
Tags: oneiric running-unity oneiric running-unity oneiric running-unity ubuntu
Uname: Linux 3.0.0-9-generic x86_64
UpgradeStatus: Upgraded to oneiric on 2011-08-13 (16 days ago)
UserGroups: adm admin cdrom davfs2 dialout lpadmin plugdev sambashare vboxusers www-data
dmi.bios.date: 06/07/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 8GET33WW (1.10 )
dmi.board.name: 7859CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8GET33WW(1.10):bd06/07/2011:svnLENOVO:pn7859CTO:pvrThinkPadL520:rvnLENOVO:rn7859CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7859CTO
dmi.product.version: ThinkPad L520
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.5.92+bzr2791-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu19
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu6
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20110811.g93fc084-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110411+8378443-1

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Stephen Rees-Carter (valorin)]

apport information

[Hernando Torque (htorque)]

Reproduced by following the steps provided in the description.

[Jeremy Bícha (jbicha)]

I was unable to reproduce by using gedit.

gnome-terminal is an unusual app and doesn't exactly resize to a particular size but sizes to a certain number of lines.

[Stephen Rees-Carter (valorin)]

Weird, I am having trouble replicating it with gedit, but I just successfully did it with these applications:

- Gwibber
- XChat
- Move Player
- gPodder

So, it seams to be some applications but not all...

@Jeremy, can you test with any/all of these to see if you can replicate it?

[Stephen Rees-Carter (valorin)]

Actually, scratch that. I just got it to happen with gedit.

When you put windows in the BOTTOM workspaces and call them from the TOP workspaces, it shifts them down so they wrap.
I've just successfully replicated it with gedit, nautilus, firefox, and gnome-terminal (as well as the others mentioned above).

@Jeremy, can you confirm?

[Jeremy Bícha (jbicha)]

Nope, it definitely doesn't duplicate here with gedit or Nautilus running in a bottom workspace and then switched to from a upper workspace. I suggest you also try unity --reset to reset your Compiz settings back to the defaults and try again.

However, apps dragged past the edge of the screen do wrap around to the other edge but I don't consider that a bug. You can always do Alt+click-drag to move windows if for whatever reason they aren't where you want them.

[Stephen Rees-Carter (valorin)]

I've run the unity --reset a couple of times since this bug showed up (for different reasons), and it hasn't helped at all.
It's a bit weird you can't replicate it... I wonder what's different between your install and mine?

I can confirm they aren't being dragged past the edge manually. Clicking on the applications in the launcher causes them to move on their own.

[Stephen Rees-Carter (valorin)]

This is a really frustrating bug, as I usually have at least one workspace with two windows side-by-side in it and not being able to use the "snap-to-side" feature to quickly position them makes it a pointless feature.

I believe this has something to do with the window border/shadow. When the border is sitting on the edge of the screen, the shadow is hanging over the edge. When the launcher is calling the window, it sees the shadow in the current workspace and moves the window slightly (for some reason) when it gives it focus rather than switching to the real workspace.

The two ways I can see to fix this are either:
A) Don't take the shadow into account when focusing on a window.
B) Switch to the workspace which has the majority of the window in it, even if some part of it is in the current window.

So... What do I need to do to get this looked at and actually fixed?
This bug existed in Natty too, but no one bothered about it either... (Bug 755842)

[Stephen Rees-Carter (valorin)]

With a recent update, this bug has just gotten a whole lot worse. Now, after using the snap-to-side feature, the window keeps moving around between different workspaces and becomes hard (and sometimes impossible) to select.

Steps to reproduce:

1) Switch to BOTTOM RIGHT workspace

2) Open Nautilus from launcher

3) Dragg Nautilus to the right to activate 'snap-to-side'

4) Open the Workspace Switcher and click on the TOP RIGHT workspace

= The Nautilus window from the BOTTOM RIGHT is now in the TOP RIGHT.

6) Open the Workspace Switcher and click on the BOTTOM LEFT workspace

= The Nautilus window is now in the BOTTOM LEFT workspace

7) Use CTRL+ALT+ARROW to switch to another workspace

8) IF the Nautilus window doesn't move automatically (sometimes it does), click it in the launcher

= it sometimes moves into the selected workspace, sometimes you switch to the right workspace, sometimes nothing happens.

[Cavia Porcellus (caviaporcellus)]

I have this problem too (glad I'm not the only one, I thought I was crazy at first). It affects all my applications, from Agave to Zim, even Firefox and LibreOffice. I just did a unity --reset and I still have it.

I think I have a slight variation from Stephen's problem though:

-If I manually extend the window in a lower workspace to the bottom of the screen, then move to an upper workspace and call it via the launcher/alt-tab, I get the problem described above: the window shifts down into the workspace above it.

-If it's touching the bottom because I used the "snap-to-side" feature, it does NOT move into the upper workspace - but instead shrinks slightly so it no longer touches the bottom!

In either case, clicking on the launcher to call the application does not actually focus on it, and while the application will appear in the alt-tab screen, it will not me allow to switch to it either, whether it moved to another workspace or just shrunk.

It's impossible to be productive unless I make extra sure all my windows are either maximized or not touching the bottom...

[Stephen Rees-Carter (valorin)]

Your experiences actually match mine now...
It's still virtually impossible to get stuff done quickly with multiple monitors and workspaces.

[Stephen Rees-Carter (valorin)]

* multiple monitors = multiple workspaces

[Stephen Rees-Carter (valorin)]

Argh... I suck at typing today. Where is the edit button?

I mean: multiple windows and workspaces.

[Miklos Juhasz (mjuhasz)]

I also experience this bug under Oneiric.
I rebuilt the compiz main plugins deb with the patch for #762335 (if window is touching the edge, compiz thinks it's on both desktops) but that made things worse: the window does not shift down but moves to the top with its title bar under the top panel.

[Miklos Juhasz (mjuhasz)]

I did some debugging and came up with a patch. I hope a compiz developer can fix this more properly.

I have 4 viewports (Oneiric default). The wall plugin has issues with windows on the outer edges, namely
- the left edge of the top/bottom left workspace
- the right edge of the top/bottom right workspace
- the bottom edge of the left/right bottom workspace

When screen->viewportForGeometry (window->geometry (), viewport); is called in wall.cpp to determine which workspace the window is placed on it returns values such as:
- y=-1 if the window is sitting on the bottom edge of a bottom workspace
- x=2 if the window is sitting on the left edge of a left workspace

In my opinion it is incorrect but I could interpret it that it wants to wrap around so from the top workspace (y=0) if I go up and wrap around (y=-1) then I end up on the bottom workspace (y=1).

The attached patch just calculates the values without wrapping around.

My feeling is that the problem may lie in the core. I did some debugging in the core and I saw that when a window is sitting on the bottom edge centerY=-266 for the window but I don't think it is correct. If I move it a few pixels up it will be something like 500 (on a resultion of 768) which makes more sense. Because of this negative center value the calculated offset in the viewportForGeometry function for y becomes -1 and (rect.centerY () / height ()) + offset=-1 so y=-1 is returned from the viewportForGeometry call. This is core however so i did not want to mess with that method and better reinterpreted the values is the wall plugin.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Eliminate wrap-around for viewport for window calculation" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount)]

I think this bug is a dupe of bug 755842. It has many more people subscribed, FYI.

[Omer Akram (om26er)]

Miklos, could you please propose the fix as a branch so more eyes could have look.

[Miklos Juhasz (mjuhasz)]

That patch is a workaround that adapts (possibly) incorrect data coming from the core into a form which is expected by the wall plugin. While testing from my ppa shows it works fine I still don't think this is the way to properly fix it.
I can propose a branch though if it helps making progress on this bug.

[Miklos Juhasz (mjuhasz)]

This problem still exists on an up-to-date precise install with compiz 0.9.7.6-0ubuntu1 and compiz-plugins-main-default 0.9.7.0~bzr19-0ubuntu10

[Cavia Porcellus (caviaporcellus)]

I've just upgraded to Precise, and the problem is still there. The behavior seems slightly different now, in that when the windows are snapped to the side, the issue doesn't occur (or at least I haven't noticed it yet - it was consistent in Oneiric). When a normal un-maximized window is sitting on the bottom of a lower workspace and is called by clicking the launcher while in an upper one, however, it is still moved and sits between the workspaces. Now it seems not just to move down into the top a bit, but move almost entirely into the upper workspace, which is even worse.

[Daniel van Vugt (vanvugt)]

Yes, I think this is a duplicate of bug 755842.

[Miklos Juhasz (mjuhasz)]

If someone needs a workaround my (updated) patch still works on precise. I have a test package in my ppa. I've been using it on Oneiric and for several weeks on precise and the problem is gone.

[Daniel van Vugt (vanvugt)]

Miklos, I just tested your patch and it seems to cause more bugs than it fixes for me. Please look at bug 755842 where smspillaz has proposed a different fix.