Window management - When a semi-maximised a window is maximised and then restored, the window position jumps and window size changes so the the window title bar is sometimes hidden underneath the top bar
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Ayatana Design |
Critical
|
John Lea | ||
| Compiz |
High
|
Brandon Schaefer | ||
| Unity Distro Priority |
Undecided
|
Unassigned | ||
| compiz (Ubuntu) |
High
|
Brandon Schaefer |
Bug Description
Note: reverting bug to triarged because the fix is not complete. When tested the correct behavour of "the window should return to exactly the same state it had at the beginning of step 1." is not fulfilled.
-------
Window management - When a Semi-maximising a window is maximised by clicking on the window decorations and then returned to the semi-maximised state, the window position jumps so the the window title bar is hidden underneath the top bar.
One way reproduce the bug:
1. Take a restored window
2. Semi-maximise the window
3. Press CTRL + SUPER + UP ARROW to maximise the window
4. Click on the 'restore' window decoration to return the window to the restored state state.
What currently incorrectly happens:
- After performing step 3, the window returns to a weird state where it is restored, but in the size and shape of a semi-maximised window, and the position is also offset from what would be expected from a semi-maximised window. This is especially problematic because in some cases the window is positioned so that all of the window title bar is underneath the top bar, making it impossible for a user to move the window without knowing a keyboard shortcut.
See the attached screencast "window_
Desired behavour:
- On pressing the 'restore' window decoration in step 4 of the bug reproduction instructions, the window should return to exactly the same state it had at the beginning of step 1.
- When fixing this bug, also review and look at fixing bug https:/
-------
Another way to reproduce the bug:
1. Semi-maximise the Thunderbird main window
2. Press the 'restore' window decoration (button on the far right of the 3 button cluster)
What currently incorrectly happens:
- The window jumps up so that the window title bar in underneath the top bar
What should happen
- The window should return to it's previous 'restored' state.
Related branches
- Daniel van Vugt: Approve on 2012-04-24
- Alan Griffiths: Approve on 2012-04-23
- Sam Spilsbury: Pending requested 2012-04-19
-
Diff: 2394 lines (+509/-779)19 files modifiedplugins/composite/src/window.cpp (+15/-35)
plugins/decor/src/decor.cpp (+66/-53)
plugins/decor/src/decor.h (+2/-3)
plugins/move/src/move.cpp (+2/-4)
plugins/opengl/src/paint.cpp (+11/-18)
plugins/opengl/src/privates.h (+7/-1)
plugins/opengl/src/window.cpp (+39/-17)
plugins/place/src/constrain-to-workarea/src/constrain-to-workarea.cpp (+4/-6)
plugins/place/src/place.cpp (+19/-24)
plugins/resize/src/resize.cpp (+1/-11)
plugins/resize/src/resize.h (+0/-2)
plugins/wobbly/src/wobbly.cpp (+5/-4)
src/event.cpp (+1/-1)
src/privatewindow.h (+7/-8)
src/screen.cpp (+4/-2)
src/window.cpp (+270/-543)
src/window/geometry/include/core/windowgeometry.h (+6/-0)
src/window/geometry/tests/window-geometry/src/test-window-geometry.cpp (+10/-0)
src/windowgeometry.cpp (+40/-47)
- Daniel van Vugt: Needs Fixing on 2012-04-19
- Sam Spilsbury: Pending requested 2012-04-18
- Alan Griffiths: Pending requested 2012-04-18
-
Diff: 2780 lines (+584/-844)21 files modifiedplugins/composite/src/window.cpp (+19/-39)
plugins/decor/src/decor.cpp (+80/-59)
plugins/decor/src/decor.h (+4/-3)
plugins/move/src/move.cpp (+10/-12)
plugins/opengl/src/paint.cpp (+11/-18)
plugins/opengl/src/privates.h (+7/-1)
plugins/opengl/src/window.cpp (+39/-17)
plugins/place/src/constrain-to-workarea/src/constrain-to-workarea.cpp (+4/-6)
plugins/place/src/place.cpp (+19/-24)
plugins/resize/src/resize.cpp (+8/-18)
plugins/resize/src/resize.h (+0/-2)
plugins/wobbly/src/wobbly.cpp (+37/-40)
plugins/wobbly/src/wobbly.h (+2/-0)
src/actions.cpp (+2/-2)
src/event.cpp (+1/-1)
src/privatewindow.h (+7/-8)
src/screen.cpp (+4/-2)
src/window.cpp (+274/-545)
src/window/geometry/include/core/windowgeometry.h (+6/-0)
src/window/geometry/tests/window-geometry/src/test-window-geometry.cpp (+10/-0)
src/windowgeometry.cpp (+40/-47)
- Daniel van Vugt: Resubmit on 2012-02-06
- Alan Griffiths: Needs Fixing on 2012-02-02
-
Diff: 1316 lines (+247/-559)9 files modifiedinclude/core/window.h (+2/-2)
plugins/composite/src/window.cpp (+16/-16)
plugins/decor/src/decor.cpp (+15/-15)
plugins/move/src/move.cpp (+1/-11)
plugins/opengl/src/window.cpp (+2/-2)
src/event.cpp (+2/-2)
src/privatewindow.h (+10/-12)
src/window.cpp (+195/-495)
src/windowgeometry.cpp (+4/-4)
- PS Jenkins bot: Needs Fixing (continuous-integration) on 2013-06-28
- Sam Spilsbury: Needs Fixing on 2013-06-21
- MC Return: Approve on 2013-06-12
-
Diff: 87 lines (+15/-8)2 files modifiedsrc/privatewindow.h (+1/-0)
src/window.cpp (+14/-8)
- PS Jenkins bot: Approve (continuous-integration) on 2013-07-18
- Sam Spilsbury: Approve on 2013-07-15
- MC Return: Approve on 2013-07-13
- Sami Jaktholm (community): Approve on 2013-07-13
-
Diff: 26 lines (+16/-0)1 file modifiedplugins/grid/src/grid.cpp (+16/-0)
tags: | added: udp |
Changed in ayatana-design: | |
assignee: | nobody → John Lea (johnlea) |
importance: | Undecided → Critical |
status: | New → Triaged |
Changed in unity: | |
milestone: | none → backlog |
status: | New → Confirmed |
Changed in unity (Ubuntu): | |
status: | New → Confirmed |
summary: |
- Window management - When a Semi-maximising a window is maximised by - clicking on the window decorations and then returned to the semi- - maximised state, the window position jumps so the the window title bar - is hidden underneath the top bar + Window management - When a Semi-maximising a window is maximised and + then restored, the window position jumps and window size changes so the + the window title bar is sometimes hidden underneath the top bar |
description: | updated |
Changed in unity (Ubuntu): | |
importance: | Undecided → Medium |
Changed in ayatana-design: | |
status: | Triaged → Fix Committed |
Changed in unity: | |
importance: | Undecided → High |
description: | updated |
Changed in unity (Ubuntu): | |
importance: | Medium → High |
summary: |
- Window management - When a Semi-maximising a window is maximised and + Window management - When a semi-maximised a window is maximised and then restored, the window position jumps and window size changes so the the window title bar is sometimes hidden underneath the top bar |
tags: | added: top5p |
Marco Trevisan (Treviño) (3v1n0) wrote : | #2 |
Changed in ayatana-design: | |
importance: | Critical → High |
importance: | High → Critical |
Changed in unity: | |
assignee: | nobody → Sam Spilsbury (smspillaz) |
RichardHDF (richardhdf) wrote : | #3 |
When one semi-maximises a window by dragging its title bar to the right and then tries to restore it by dragging its title bar away from the top, the window also jumps quite far away from the cursor while still holding in the click. This behaviour is quite awkward. Was this also fixed in this commit?
Changed in unity-distro-priority: | |
status: | New → Fix Committed |
tags: | added: rls-p-tracking |
Sam Spilsbury (smspillaz) wrote : | #4 |
This is a race condition and won't be fixed until Q. See lp:~smspillaz/compiz-core/compiz-core.work_923683
tags: | removed: rls-p-tracking |
Changed in compiz-core: | |
status: | New → In Progress |
assignee: | nobody → Sam Spilsbury (smspillaz) |
importance: | Undecided → High |
milestone: | none → 0.9.7.8 |
Changed in unity: | |
milestone: | backlog → 5.12.0 |
affects: | unity (Ubuntu) → compiz (Ubuntu) |
Launchpad Janitor (janitor) wrote : | #5 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in unity (Ubuntu): | |
status: | New → Confirmed |
Can you just hold alt and drag the window down in order to see the titlebar again? Or is alt+dragging no longer a default?
John Lea (johnlea) wrote : | #7 |
@hugo.osvaldoba
Daniel van Vugt (vanvugt) wrote : | #8 |
Fix committed into lp:compiz-core at revision 3110.
Changed in unity: | |
milestone: | 5.12.0 → 5.14.0 |
Changed in compiz: | |
milestone: | none → 0.9.8.0 |
status: | New → Fix Committed |
importance: | Undecided → High |
assignee: | nobody → Sam Spilsbury (smspillaz) |
no longer affects: | compiz-core/0.9.7 |
no longer affects: | compiz-core/0.9.8 |
Changed in compiz-core: | |
milestone: | 0.9.8.0 → none |
no longer affects: | compiz-core |
Changed in unity: | |
status: | Confirmed → Triaged |
Changed in unity (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in compiz (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in unity (Ubuntu): | |
importance: | Undecided → High |
Daniel van Vugt (vanvugt) wrote : | #9 |
I'm not sure this should be assigned to unity. Looks like just a compiz bug (now fixed).
description: | updated |
Changed in unity: | |
milestone: | 5.14.0 → 5.16.0 |
Omer Akram (om26er) wrote : | #10 |
Would have been nice to see this as SRU but the change looks non trivial for an SRU. Also wondering should unity be removed as affects now?
no longer affects: | unity (Ubuntu) |
Omer Akram (om26er) wrote : | #11 |
(upstream one)
Omer Akram (om26er) wrote : | #12 |
Now in Quantal we have bzr 3249 should we close this bug as fixed now?
Changed in compiz: | |
status: | Fix Committed → Fix Released |
Daniel van Vugt (vanvugt) wrote : | #13 |
This bug was fixed in the package compiz - 1:0.9.8.0-0ubuntu1
---------------
compiz (1:0.9.
* debian/control, debian/rules:
- enable gles on armel and armhf
- use dh-translations rather than custom code
[ Sam Spilsbury ]
* Enable OpenGL ES building
- Refresh debian/
- Remove non-ported plugins from compiz-plugins
- Add FindOpenGLES2.cmake to compiz-dev
[ Timo Jyrinki ]
* New upstream release.
- Code to make compiz work on GLES. This includes several changes
to the compiz API. (LP: #201342) (LP: #901097) (LP: #1004251)
(LP: #1037710)
- Draft first 0.9.8.0 NEWS and bump VERSION
* debian/
- Remove, obsoleted by the upstream GLES work
* Disable plugins that don't work on pure GLES on armhf/armel:
- bench, firepaint, mblur, showmouse, splash, showrepaint, td, widget
-- Sebastien Bacher <email address hidden> Fri, 31 Aug 2012 22:59:50 +0200
Changed in compiz (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in unity: | |
milestone: | 5.16.0 → 5.18.0 |
Changed in unity: | |
milestone: | 5.18.0 → none |
status: | Triaged → Invalid |
Changed in unity (Ubuntu): | |
status: | New → Invalid |
Changed in unity (Ubuntu): | |
importance: | Undecided → High |
John Lea (johnlea) wrote : | #14 |
Reverting bug to triarged as issue is not completly fixed, see note added to top of description.
description: | updated |
Changed in compiz: | |
status: | Fix Released → Triaged |
Changed in unity-distro-priority: | |
status: | Fix Committed → Confirmed |
Changed in compiz (Ubuntu): | |
status: | Fix Released → Triaged |
no longer affects: | unity |
no longer affects: | unity (Ubuntu) |
Changed in compiz: | |
milestone: | 0.9.8.0 → 0.9.10.0 |
assignee: | Sam Spilsbury (smspillaz) → Brandon Schaefer (brandontschaefer) |
Changed in compiz (Ubuntu): | |
assignee: | nobody → Brandon Schaefer (brandontschaefer) |
Changed in compiz: | |
status: | Triaged → In Progress |
Changed in compiz (Ubuntu): | |
status: | Triaged → In Progress |
MC Return (mc-return) wrote : | #15 |
AFAIK this bug has already been fixed in trunk.
Changed in compiz: | |
status: | In Progress → Fix Committed |
MC Return (mc-return) wrote : | #16 |
@ MC
Part of it was, now that im looking at trunk (but im also having problems running unity/compiz atm).
But the Semi max -> Full Max -> Restore is what this bug is about. As when you doing a Full max it doesn't touch the grid plugin...soo im marking this back as in progress...
Changed in compiz: | |
status: | Fix Committed → In Progress |
MC Return (mc-return) wrote : | #18 |
Well, I cannot reproduce this particular bug...
But bug #1115341 is still open - maybe you want to look into that one ?
(I had no time to fix it yet)
Well let me get trunk compiz running and confirm its fixed ... as this could be only a problem in the compiz/raring branch
MC Return (mc-return) wrote : | #20 |
Sure...
Im still getting this very close to trunk (for some reason trunk compiz seems to hate me atm...). Soo im going to propose a branch later today to fix this. :)
PS Jenkins bot (ps-jenkins) wrote : | #22 |
Fix committed into lp:compiz at revision 3762, scheduled for release in compiz, milestone 0.9.10.0
Changed in compiz: | |
status: | In Progress → Fix Committed |
Changed in compiz (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in compiz: | |
status: | Fix Committed → Fix Released |
Launchpad Janitor (janitor) wrote : | #23 |
This bug was fixed in the package compiz - 1:0.9.10+
---------------
compiz (1:0.9.
[ Sam Spilsbury ]
* Bump version to 0.9.10
[ Łukasz 'sil2100' Zemczak ]
* Remove debian/
- 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
kdecoration
http://
(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-
min, max) buttons on the title bar is pressed. (LP: #1101648)
* Remove redundant src/logmessage/
#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
setWindowFr
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 |
tags: | added: rls-w-incoming |
I can't reproduce this anymore with newest compiz, please check it again.