Grid placed window overlaps the adjacent viewport

Bug #898870 reported by 123456789
226
This bug affects 46 people
Affects Status Importance Assigned to Milestone
Compiz
Low
Sami Jaktholm
Compiz Grid Plugin
Low
Unassigned
Compiz Main Plugins
Low
Unassigned
Unity
Invalid
Low
Unassigned
compiz (Ubuntu)
Undecided
Unassigned
compiz-plugins-main (Ubuntu)
Low
Unassigned

Bug Description

When using the grid plugin's "Put Right" method, the right edge of the window extends beyond the border between workspaces. When using Unity with "Hide Launcher" set to "Dodge Windows", the launcher hides when switching to the workspace to the right.

The horizontal virtual desktop size must be 2 or more for the unexpected behavior to occur.

"Put Left" works as expected.

Related branches

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Confirmed. Though I think this may be a duplicate...

Attached a screenshot showing the window overlapping the next workspace by 2 pixels, excluding shadow.

Changed in compiz-grid-plugin:
status: New → Confirmed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This bug seems to apply to "put left" too. Because if you have a window on the left AND right then the left one overlaps the right one by a few pixels. Probably the same bug; miscalculated width of the grid-placed windows.

Changed in compiz (Ubuntu):
status: New → Confirmed
Changed in compiz-grid-plugin:
assignee: nobody → Daniel van Vugt (vanvugt)
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

A while ago I had a look at fixing this bug. And I partially succeeded but it still felt broken due to bug 925867. I think that one needs to be fixed first.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The other reason I couldn't propose a fix for this bug was because of the much more severe problem of bug 910698.

affects: compiz-grid-plugin → compiz-plugins-main
Changed in compiz-plugins-main:
status: Confirmed → Triaged
Changed in compiz-grid-plugin:
status: New → Triaged
assignee: nobody → Daniel van Vugt (vanvugt)
summary: - "Put right" extends window past edge of workspace
+ Grid placed window overlaps the adjacent workspace
affects: compiz (Ubuntu) → compiz-plugins-main (Ubuntu)
Revision history for this message
Achim Behrens (k1l) wrote : Re: Grid placed window overlaps the adjacent workspace

still same problem here with dualview setup. when using the "put right" thing on the left monitor the windows reaches to the other (right) monitor for some pixels.

uptodate 12.04 with compiz-plugins-main_0.9.7.0~bzr19-0ubuntu2_amd64.deb

Omer Akram (om26er)
tags: added: spread
affects: compiz-grid-plugin → unity
Changed in compiz-grid-plugin:
status: New → Triaged
Changed in compiz-plugins-main (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
matt.j.crowther (matthew-j-crowther) wrote :

http://dl.dropbox.com/u/55796070/out.ogv

This bug still exists in precise and I *think* it may be what's responsible for some weird behaviour I've been experiencing (see video).
There also seems to be another bug in there too (where the grid isn't triggered when it should be ).

This is 100% a grid problem as windows not placed using the grid plugin don't behave like this when their icons are clicked on from another workspace. It also only appears to apply to the right grid on the right hand workspace, but don't quote me on that, although I can't repeat it by putting left on the left workspace.

Changed in compiz-grid-plugin:
importance: Undecided → Low
Changed in compiz-plugins-main:
importance: Undecided → Low
Changed in unity:
importance: Undecided → Low
Changed in compiz-plugins-main (Ubuntu):
importance: Undecided → Low
Revision history for this message
zazzko (dinobg) wrote :

Same problem here. When grid function is used (aka Aero Snap) right window on second viewport from first row overlaps on first one. This cause some wierd behavior when using Unity switcher (window is moved to first viewport).

Revision history for this message
matt.j.crowther (matthew-j-crowther) wrote :

Probably already been thought of, but can't bugs like this be fixed by changing the way compiz deals with workspaces.

Metacity under Gnome Fallback (which I use on my netbook as an alternative to Unity 2D), keeps workspaces totally separate. If things are moved to one side and sent over the edge they don't overlap another workspace. It's like each desktop is exactly that, it's own desktop as opposed to the sort of "flowing" model compiz has. Even more so when the window list is set to just show the current workspace's windows.

Couldn't compiz be made to do this, I can see it fixing a lot of problems. I can't see any case where having windows cross workspaces could be practical, actually quite to the contrary as shown by bugs like this. It's not even practical to use it as a tool for moving windows workspace to workspace as the title bar has to be dragged and that's always stuck on one workspace anyway. Expo/switcher and keyboard shortcuts are a lot more practical and convenient (for me at least).

Just an idea... probably over simplifying this a lot here, don't know the slightest thing about the backend of things :P Sorry...

summary: - Grid placed window overlaps the adjacent workspace
+ Grid placed window overlaps the adjacent viewport
Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Daniel Sommermann (dcsommer) wrote :

This bug has been bothering me quite a bit, and I'm interested in taking a look at it, although I have never developed for Compiz or Unity before. Can anyone with experience tell me the process with which they would go about fixing this? I'm guessing I would set up a VM with Ubuntu 12.04, compile and install compiz/unity from source. Any tips on debugging compiz in general?

Revision history for this message
Justyn Butler (justyn) wrote :

One side effect of this bug (at least, I assume this bug is the cause) is that when using alt-tab on a viewport which has a window from an adjacent workspace intruding 2px into it, selecting the unwanted window causes that window to fully move onto the current viewport.

My hardware setup is a single monitor plugged into an X220 laptop, with the laptop screen disabled (but the monitor is higher resolution than the laptop screen). I'm not sure if this qualifies as "horizontal virtual desktop size" of two or more.

Revision history for this message
Andrew (andrewkvalheim) wrote :

Screenshots of this affecting "put left" are included in bug 1038533.

Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz-plugins-main:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in unity:
assignee: Daniel van Vugt (vanvugt) → nobody
Revision history for this message
Jan Taborsky (jantaborsky) wrote :

Still affected by this on Ubuntu 12.10.
compiz-plugins-main: 1:0.9.8.4-0ubuntu3

Revision history for this message
Daniel Sommermann (dcsommer) wrote :

I just checked out, built, and installed the grid plugin from the compiz project via the directions on http://wiki.compiz.org/Plugins/Grid and it seems to be fixed on my machine now. Not sure how the dependencies are determined in Ubuntu, but any reason we don't just update compiz-plugin-main dependencies to grab a newer version of Grid?

Revision history for this message
Daniel Sommermann (dcsommer) wrote :

Sorry quick update on repro: It does not repro with nautilus for me, but firefox for instance DOES show the described bug behavior of "Put Right" showing 2px on the adjacent viewport.

Changed in compiz:
milestone: none → 0.9.9.0
Revision history for this message
Ryan Tandy (rtandy) wrote :

Justyn Butler wrote:
> One side effect of this bug (at least, I assume this bug is the cause)
> is that when using alt-tab on a viewport which has a window from an
> adjacent workspace intruding 2px into it, selecting the unwanted
> window causes that window to fully move onto the current viewport.

Yup. Scale (Super-W) does that for me too.

I run GNOME Classic (on precise), and the slight overlap is enough that
gnome-panel registers the window as existing on both workspaces. Unity
doesn't do that, for some reason.

My setup is a single display at 1920x1080.

Revision history for this message
Alden Davidson (davidsonalden) wrote :

Don't know if this changes anything, but I felt I should add that under Xubuntu 12.10 this bug also occurs -
the CompizConfig Settings Manager extends too far right when placed with Put Left, and extends off the right side of the screen when placed with Put Right.

Photos of both bugs:
http://i.imgur.com/qWs8nh.jpg
http://i.imgur.com/pt6Dlh.png

Running Xubuntu 12.10 with a single workspace.

Revision history for this message
Sicco van Sas (sicco) wrote :

The bug also affects me on Ubuntu 12.04. If I semi-maximize a window to the right half of the screen, 2 pixels of the window will show on the workspace to the right of it. Just like Justyn Butler describes, Alt + Tab on the workspace to the right shows the window and if selected moves the window to that workspace.

This bug is reproducible when dragging the window to the right so it snaps to the right half. This behavior doesn't always occur when using keyboard shortcuts. If I press Ctrl + Super + Up (maximization) and then Ctrl + Super + Right, the window will only run over to the right workspace by 1px (this also removes the Alt + Tab problem!). Pressing Ctrl + Super + Right after Ctrl + Super + Left or Ctrl + Super + Down the window runs over by 2px again.

Windows from all programs (nautilus, firefox, terminal) seem to be affected by this,

Revision history for this message
Anish Narayanan (anish-narayanan32) wrote :

I noticed that the degree to which the overlap is present on the next workspace is based on the width of the window borders listed in the user's theme. I edited the metacity-theme-1.xml file for my theme to resolve this problem. Simply go to the section of the file listing <frame_geometry name="frame_geometry_normal" ... > and underneath that, set left_width and right_width to 0 (set bottom_height to zero for visual consistency). This gets rid of the overhang, but I think the shadow is still present in the adjacent workspace. Setting the width to anything other than zero leads to an overhang that is twice that width on the next workspace.

Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Revision history for this message
mdc (nexuscomputing) wrote :

Thanks for #13!

Going to http://wiki.compiz.org/Plugins/Grid and following the build instructions not only fixed the problem, but I also have the 1/3.1/4,1/5 Horizontal Splits again! Thank you so much!

One thing I notices was that I got a compile error

fatal error: boost/function.hpp: No such file or directory
compilation terminated.

Which was fixed by installing the libboost-dev package.

Thanks so much!

Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0
MC Return (mc-return)
Changed in compiz:
assignee: nobody → MC Return (mc-return)
Revision history for this message
MC Return (mc-return) wrote :

Hmmm, I cannot reproduce this @ the moment...

Changed in compiz:
assignee: MC Return (mc-return) → nobody
Revision history for this message
Niklas Rosenqvist (niklas-s-rosenqvist) wrote :

I can still reproduce this in 13.10. The edge of the window is still visible on the next workspace. If you "put right" a window and move to the next workspace it's still visible in the alt+tab switcher. It doesn't behave like this 100% of the times now when I'm testing this, more like 50%, I'm not sure if it has something to do with what window is focused when you switch workspace. Although it's clear that this issue still exists.

Sami Jaktholm (sjakthol)
tags: added: grid
removed: spread
Sami Jaktholm (sjakthol)
Changed in compiz:
assignee: nobody → Sami Jaktholm (sjakthol)
status: Triaged → In Progress
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz at revision None, scheduled for release in compiz, milestone 0.9.10.0

Changed in compiz:
status: In Progress → Fix Committed
Revision history for this message
Stephen M. Webb (bregma) wrote :

Fix Released in Compiz Compiz 0.9.10.0.

Changed in compiz:
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (70.8 KiB)

This bug was fixed in the package compiz - 1:0.9.10+13.10.20130822-0ubuntu1

---------------
compiz (1:0.9.10+13.10.20130822-0ubuntu1) saucy; urgency=low

  [ Sam Spilsbury ]
  * Bump version to 0.9.10

  [ Łukasz 'sil2100' Zemczak ]
  * Remove debian/patches/unity_support_test.patch:
    - Running the support test from compiz has bad side effects, from now
      on we run it from Xsession.d
  * Automatic snapshot from revision 3644

  [ Iven Hsu ]
  * Opacify: Only dim the windows above the active window.(LP:
    #1189374). (LP: #1189374)
  * KWD: Fix compile errors with KDE 4.11. The KWin developers made
    kdecorationbridge.h private. See:
    http://lists.freedesktop.org/archives/compiz/2013-March/003479.html
    (LP: #1193792). (LP: #1193792)

  [ Nikolay Martynov ]
  * When static switcher is enabled and has an option to show
    application icon turned on the icons are expected to be ~1/3 of a
    thumbnail (48px). Instead they are displayed in 512px size and
    completely cover everything. This change addresses this issue. See
    LP #1173914. (LP: #1173914, #1186426)

  [ BryanFRitt ]
  * Fixed the non-working Annotate 'Clear' Button. Moved this option's
    CCSM position upwards to keep the button shortcuts together. (LP:
    #1202907). (LP: #1202907)

  [ Mehrdad Afshari ]
  * Added "move window to previous monitor" feature to compiz Put
    plugin. (LP: #1178581)

  [ Hu Kang ]
  * gtk-window-decorator: destroy action menu when any of the (close,
    min, max) buttons on the title bar is pressed. (LP: #1101648)
  * Remove redundant src/logmessage/include/core/logmessage.h (LP:
    #1067246). (LP: #1067246)

  [ Steve Langasek ]
  * Fix for bug #763148 (with added test cases): when the desktop is
    resized, windows should stay on their original workspace. (LP:
    #763148)

  [ Brandon Schaefer ]
  * Unrevert 3728, fix failing tests. Change the behaviour of
    undecorating windows. Previously when a window was undecorated, we
    would shift it back to an appropriate position according to its
    gravity member. That behaviour was problematic because in the
    StaticGravity case the window has to just stay in the same place.
    But then if you had a window with StaticGravity which then did get a
    decoration and later removed it, it would be placed as though it was
    decorated and appear to be in the wrong place. The correct behaviour
    is to place all windows as though they have decorations, and then
    when decorations are removed, to move the window back to the corner
    as indicated in its gravity and then expand its size to cover the
    obscured regions no longer hidden because the decorations went away.
    (LP: #1165343).   1. Completely remove decorOffsetMove and other
    related code from      decor.cpp. Put the logic to handle the
    window->input () - window->border ()      placement offset inside of
    setWindowFrameExtents instead. Now the window      will always be
    offset from its original non-decorated position to the new
         decorated position, rather than having to guess between
    decoration sizes.   2. Make saveGeometry and restoreGeometry work
    relative to window->border ()      a...

Changed in compiz (Ubuntu):
status: New → Fix Released
Stephen M. Webb (bregma)
Changed in unity:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.