Regression: r3751 causes all unmaxed windows to shrink both horizontally and vertically on each subsequent opening, probably by exactly the size of the decoration

Bug #1198000 reported by Doug McMahon
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
High
Andrea Azzarone
compiz (Ubuntu)
Fix Released
Critical
Andrea Azzarone

Bug Description

[How to reproduce]

1. Tip: Enable CCSM->Resizeinfo to have exact values for the size.
2. Open and optionally resize any window to a specific size (for example nautilus, gedit, gimp, smplayer, size example 500x500 pixels)
3. Close the window.
4. Reopen the same window.

[What you would expect to happen]

The window should reopen with the same size you resized it to before you closed it.

[What actually happens]

The window reopens, but is smaller now.
Resize it again to see that it has shrunk horizontally and vertically, probably by exactly the size of your decoration.

IMPORTANT NOTE:
This is a showstopper bug for the imminent 0.9.10.0 release !

Original description:
=====================
Pretty obvious, install r3751 or higher.
Open, close, re-open an unmaxed nautilus window, it will have shrunk vertically
Seems to shrink 29 px. here until height reaches 200px, then it stops

Related branches

MC Return (mc-return)
Changed in compiz:
milestone: none → 0.9.10.0
importance: Undecided → Critical
status: New → Triaged
summary: - Regession: r3751 causes unmaxed windows to shrink vertically on each
+ Regression: r3751 causes unmaxed windows to shrink vertically on each
subsequent opening
MC Return (mc-return)
Changed in compiz:
importance: Critical → High
MC Return (mc-return)
Changed in compiz:
importance: High → Critical
MC Return (mc-return)
summary: - Regression: r3751 causes unmaxed windows to shrink vertically on each
- subsequent opening
+ Regression: r3751 causes all unmaxed windows to shrink vertically on
+ each subsequent opening
Revision history for this message
MC Return (mc-return) wrote : Re: Regression: r3751 causes all unmaxed windows to shrink vertically on each subsequent opening

Here it shrinks by 32 pixels vertically, but also by 10 pixels horizontally, might be exactly the decoration size.

Can anyone confirm ?

MC Return (mc-return)
description: updated
summary: - Regression: r3751 causes all unmaxed windows to shrink vertically on
- each subsequent opening
+ Regression: r3751 causes all unmaxed windows to shrink both horizontally
+ and vertically on each subsequent opening, probably by exactly the size
+ of the decoration
Revision history for this message
Doug McMahon (mc3man) wrote :

I get
minus 28+1 on the vertical (deco + window border of 1 px bottom
minus 2 on the horizontal (l, r border of 1 px. each
attached xwininfo

If i was to go 'borderless' (metacity-theme-1.xml) then no horizontall & 28 px on vertical

Revision history for this message
MC Return (mc-return) wrote :

Doug, thanks a lot for re-testing ;)
+1

Changed in compiz (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
Revision history for this message
Sam Spilsbury (smspillaz) wrote :

https://wiki.ubuntu.com/Bugs/Importance

Critical: A bug which has a severe impact on a large portion of Ubuntu users
Causes data corruption
Crashes the entire operating system
Renders the system temporarily or permanently unusable
Severely affects applications beyond the package responsible for the root cause

Changed in compiz:
importance: Critical → High
Revision history for this message
MC Return (mc-return) wrote :

Regarding the "Critical" status:

It is quite obvious that landing this in Ubuntu would clearly have "a severe impact on a large portion of Ubuntu users" and also "severely affect applications beyond the package responsible for the root cause".

After all Compiz is a window manager and users expect correct window management from it, especially no regressions there and *every application with deco* is now affected by the shrinking, so IMHO this bug is really a showstopper...

Revision history for this message
MC Return (mc-return) wrote :

Another note:

http://bazaar.launchpad.net/~compiz-team/compiz/0.9.10/revision/3728

fixed bug #1009570 "Emerald: Sometimes all Emerald buttons disappear when restoring a maximized window, sometimes the restored window decoration appears to be unfocused" reliably for me, unfortunately it had other regressions.

I was really happy about this great side-effect of r3728. So I was *very* excited when I read that

http://bazaar.launchpad.net/~compiz-team/compiz/0.9.10/revision/3751

unreverts r3728 and fixes the problems, but it seems that it does not really do that.
Now the buttons are not only sometimes gone, but always :(.

(I know "Emerald is dead" and "Emerald is not supported" and "Emerald does not compile anymore" and "Emerald is broken", but this has nothing to do with Emerald as Compiz r3728 clearly showed.)

Sam, do you have an idea why
*r3728 fixed the button problem (almost) completely (~1 of 25 times the buttons disappeared), while
*before r3728 the buttons disappeared ~1 of 3 times and
*now with r3751 the buttons always vanish ?

Andrea Azzarone (azzar1)
Changed in compiz:
assignee: nobody → Andrea Azzarone (andyrock)
Changed in compiz (Ubuntu):
assignee: nobody → Andrea Azzarone (andyrock)
Changed in compiz:
status: Triaged → Won't Fix
status: Won't Fix → Confirmed
status: Confirmed → In Progress
Changed in compiz (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Doug McMahon (mc3man) wrote :

The proposed small adjustment is working out ok here, tested for the last day on compiz trunk in raring, no apparent side issues

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in compiz:
status: In Progress → Fix Committed
Andrea Azzarone (azzar1)
Changed in compiz (Ubuntu):
status: In Progress → Fix Committed
Stephen M. Webb (bregma)
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: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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