Segfault in compiz when unchecking "Snap windows back to original size" in the Grid options

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

I have this problem on Xubuntu 11.10 both with unity-decorator and gtk-window-decorator.

I guess that it's a "compiz" bug, and not the settings-manager, but it does affect me with the latest version at this date.
I hoped yesterday's compiz updates had solved it but didn't...

Ubuntu 12.04 with default Unity bug still exists

I confirm compiz crash when I remove the option "Snap windows back to original size" win Ubuntu 12.04

A fix is apparently available in bug 932193

Still present in Quantal in Compiz version 0.9.8.3.
Can the bug be assigned to someone? Pretty please :) ....'m waiting 18months for resolved status

Wow, still present in Raring! (just upgraded)

The crash is easy to fix, but the design makes no sense...

"Move" is responsible for Snapoff/Snapback of semimaximized/maximized windows.
So if the user wants to adjust those settings and disable snapoff, he can and should do it there.

Solution: This option should be completely removed.

@asala: Please read this ^^

The problem also is that Compiz 0.9.9 has no idea about snapping of horizontally semi-maximized windows.

This is fixed in 0.9.10 already:
https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1165198-horizontally-semimaximized-windows-do-not-snap-off-easily/+merge/158508

This is how the move plugin in 0.9.10 CCSM looks:

Here you can find a low quality screencast demonstrating the Move Snapoff/Snapback options in action :)
https://bugs.launchpad.net/compiz/+bug/1167933/+attachment/3642013/+files/Screencast-showing-move-fixes-and-upgrade.vob

The video looks nice. However, "grid" plugin is not "move" plugin: from a semi-advanced user perspective (that's what I, plainly, am), I just don't like having checkboxes to play with which crash my system (2 years standing): if it does never work, disable it in "release" ubuntu (i.e., assume always checked and hide in the user interface)... as comment #10 suggests.

However, from an user perspective, I thing the snapoff/snapback in "maximized" hasn't the same meaning as in "gridded" windows: For me, I'd like the grid plugin to be a fast way of changing size of a window without touching my mouse. So, when I try to uncheck the option it's because I just want that: I don't want any "maximized"-like interpretation, just change size and move around that smaller window. So, I think the design "does make sense".

A different thing is the behaviour shown in the "move" plugin video: the snapoff makes you avoid one step of "1st minimize, then move" a maximized or semi-maximized window. That's useful, too.

In summary, both designs can coexist and make sense; my ideal combined user interface would be:
1) Move, drag to an edge, maximise buttons: window gets maximised as expected (full, half left, horiz, etc.)... move it and you restore size.
2) Grid: change size of the window, no default "semi-maximised" interpretation. Move and it keeps the size set by the grid.

If the grid plugin UI as it stands now has the checkbox and it does not crash, then it's up to the user the interpretation of the grid window size changes. I prefer "2" (but cannot do it because of the bug); if others prefer "1", good: user flexibility wins. In fact, the most flexible interface would be selecting "snapoff fully maximised windows true/false", "snapoff semimaximised (left,right,top,bottom) windows true/false", "snapoff all gridded windows (i.e., the 9 combinations) true/false".

So, if it's easy to fix and I convinced you the design makes sense (for some of us at least), maybe you might think fixing it.

@asala:
I am working on a nice solution. You are of course right -> CCSM should never crash Compiz ;)
I was not aware this bug still existed, otherwise I would have fixed it probably earlier, it is already fixed here locally now.

You are of course right - I am the last person who will take away an useful option from the user, btw ;) - I thought about users who might want to not "Snap Windows Back To Original Size" to use Grid as fast resize...

But the "Snapoff Semi- & Maximized Windows" is already in Move and thus is not needed twice.

One thing that could be made configurable is if you want the window to be moved back to its original position, if gridded and restored via keys...

Thanks for your fix... I hope it gets comitted on ubuntu bug fixes somehow soon even if you did on the 0.9.10 branch.
Your las option seems sound: the "restore" keyboard shortcut should bring the window back to its original position and size whatever the "snap" checkbox state is (at least, I can't think of any other direct interpretation on what "restore" should be otherwise).

@asala and @ all others who are affected and want to test:

The branch linked here fixes this bug and implements the correct behaviour.

It is still WIP, because Grid is broken beyond belief...

The cursor calculation is also broken and needs multiple fixes...

Grid and Put(https://bugs.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/684019) plugins are very useful when it comes to effective window management. Greatly appreciated that finally those issues being addressed.

Here is a snek preview video, showing all new Grid functionality !!! :)
(except the now configurable snapoff distance, which is also already fully working)

The only minor issue left (you can also see it in the video) is the wrong cursor positioning, when snapping off vertically semi-maximized windows -> A minor thingy that I will nevertheless eliminate also ;)

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

@mc-return: Do your modifications to Grid also solve the following problem? When snapping terminal windows (e.g. terminal, terminator, konsole) to the screen edge so that they mazimize fully (top-edge) or on one side (left-edge, right-edge) and then dragging them off again, they do not restore to their original size - most of the time, but not always.

@master-of-past-and-present:
No, unfortunately not -> gnome-terminal windows are a bit special and can still make problems sometimes...

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...