[Grid] Window restored to wrong position if it was fully maximized by Grid plugin

Bug #1020857 reported by Sami Jaktholm
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
Medium
MC Return
compiz (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Steps to reproduce:
1. Place an unmaximized window to bottom of the screen.
2. Maximize the window by dragging it to the top of your screen.
3. Unmaximize it by pressing restore window decoration(1) or grid restore key binding (CTRL + ALT + R) (2).

What should happen?
- Window restores its original size and position (at the bottom of your screen)

What happens?
- Window is placed to fixed position on top left corner of the screen at (50, 50).

Why?
If window is being moved by mouse, the window is placed to (50, 50) of the current workarea to make sure it maximizes to right workspace. The window state is saved(*) at maximize event _after_ reposition operation and when it's restored, window returns to (50, 50).

(*) (1) by another plugin, (2) GridWindow::stateChangeNotify on line 863

Tags: grid

Related branches

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

Sounds related to bug 878516.

Changed in compiz:
milestone: none → 0.9.8.0
Revision history for this message
Sami Jaktholm (sjakthol) wrote :

Although this is kinda related to bug 878516 it's really caused by different issue (workaround for both of these bugs could be bundled together).

But as the code causing this issue is written to work around bug #776435, it should be fixed first and after that the workaround should be removed to fix this bug (I think it's better solution than working around a bug caused by workaround :)).

Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
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)
status: New → Confirmed
Revision history for this message
MC Return (mc-return) wrote :

I commented out the code responsible for this bug in the branch attached - it makes no sense to me at all...

+50 +50 magic numbers ?

I cannot reproduce any regressions without it...

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

Well, we should simply restore it, where it was dragged to -> which is what happens in the branch attached.

Changed in compiz:
status: Confirmed → In Progress
Revision history for this message
Sami Jaktholm (sjakthol) wrote :

Drag the window near top right corner and maximize it with grid (by dragging) --> window maximizes in a different workspace. That's the reason the code exists.

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

@sjakthol: Well, that one is a (other) design problem in itself ;)

As you probably might know, core is responsible for this behaviour -> it was coded that way. -
The window will always maximize on the workspace the most part of it is on...
(see bug #776435 for details)

I agree this should be fixed, but not in Grid, but Core...

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

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

Changed in compiz:
status: In Progress → Fix Committed
MC Return (mc-return)
Changed in compiz:
importance: Undecided → Medium
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: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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