Merge into trunk : trunk.fix_757434 : Code : Compiz

Status:	Merged
Merge reported by:	David Barth
Merged at revision:	not available
Proposed branch:	lp://qastaging/~unity-team/compiz/trunk.fix_757434
Merge into:	lp://qastaging/~unity-team/compiz/trunk
Diff against target:	120 lines (+47/-33) 1 file modified src/window.cpp (+47/-33)
To merge this branch:	bzr merge lp://qastaging/~unity-team/compiz/trunk.fix_757434
Related bugs:	Link a bug report

Reviewer	Date Requested	Status
Didier Roche-Tolomelli		Needs Information on 2011-04-14
David Barth (community)	2011-04-14	Needs Information on 2011-04-14
Review via email: mp+57630@code.qastaging.launchpad.net

Revision history for this message

David Barth (dbarth) wrote on 2011-04-14:

#

The code change itself looks safe. Its impact on the window stack sounds rather significant, with a potential to impact other use cases.

Can you argument why the change will not impact regular windows, not introduce regressions. Alternatively, are there simple test procedures to ensure that regressions do not occur with the change?

review: Needs Information

Revision history for this message

Sam Spilsbury (smspillaz) wrote on 2011-04-14:

#

This case is only hit where a window is being restacked above a
fullscreen window (eg for when a window opens newly, or when a window
is activated and needs to be presented above a fullscreen window). In
this case, we should never ever stack a normal window above a panel or
dock, so we need to restack the docks appropriately (so that the docks
and launcher appear *above* the fullscreen window and the normal
window, this is in intention of the code at present).

The problem was that xwc.sibling at this point is *still* the sibling
window of the normal which is the one being restacked, which happens
to be the fullscreen window. And these dock windows are being
restacked *according* to this xwc, which means that dock windows were
going under normal windows which should never ever happen. This change
ensures that dock windows *always* stay on top of other windows.

Testcase

1) Fullscreen a window
2) Alt-tab to another winow
3) check if you can alt-drag that window what was just selected above
the dock. You shouldn't be able to
4) switch back to the fullscreen window and unfullscreen it
5) check if you can move the previously fullscreened window above the
panels and docks
6) switch back to the window activated during alt-tab and check if
this window can go above panels.

In no case should any window be allowed above the panels and docks.

On Thu, Apr 14, 2011 at 5:49 PM, David Barth <email address hidden> wrote:
> Review: Needs Information
> The code change itself looks safe. Its impact on the window stack sounds rather significant, with a potential to impact other use cases.
>
> Can you argument why the change will not impact regular windows, not introduce regressions. Alternatively, are there simple test procedures to ensure that regressions do not occur with the change?
> --
> https://code.launchpad.net/~unity-team/compiz/trunk.fix_757434/+merge/57630
> Your team Unity Team is subscribed to branch lp:~unity-team/compiz/trunk.
>

--
Sam Spilsbury

This case is only hit where a window is being restacked above a
fullscreen window (eg for when a window opens newly, or when a window
is activated and needs to be presented above a fullscreen window). In
this case, we should never ever stack a normal window above a panel or
dock, so we need to restack the docks appropriately (so that the docks
and launcher appear *above* the fullscreen window and the normal
window, this is in intention of the code at present).

The problem was that xwc.sibling at this point is *still* the sibling
window of the normal which is the one being restacked, which happens
to be the fullscreen window. And these dock windows are being
restacked *according* to this xwc, which means that dock windows were
going under normal windows which should never ever happen. This change
ensures that dock windows *always* stay on top of other windows.

Testcase

1) Fullscreen a window
2) Alt-tab to another winow
3) check if you can alt-drag that window what was just selected above
the dock. You shouldn't be able to
4) switch back to the fullscreen window and unfullscreen it
5) check if you can move the previously fullscreened window above the
panels and docks
6) switch back to the window activated during alt-tab and check if
this window can go above panels.

In no case should any window be allowed above the panels and docks.

On Thu, Apr 14, 2011 at 5:49 PM, David Barth <david.barth@canonical.com> wrote:
> Review: Needs Information
> The code change itself looks safe. Its impact on the window stack sounds rather significant, with a potential to impact other use cases.
>
> Can you argument why the change will not impact regular windows, not introduce regressions. Alternatively, are there simple test procedures to ensure that regressions do not occur with the change?
> --
> https://code.launchpad.net/~unity-team/compiz/trunk.fix_757434/+merge/57630
> Your team Unity Team is subscribed to branch lp:~unity-team/compiz/trunk.
>

-- 
Sam Spilsbury

Revision history for this message

Didier Roche-Tolomelli (didrocks) wrote on 2011-04-14:

#

Does it take into account the systray we added and the screensaver?

review: Needs Information

Revision history for this message

Sam Spilsbury (smspillaz) wrote on 2011-04-14:

#

> Does it take into account the systray we added and the screensaver?

It does now :)

lp://qastaging/~unity-team/compiz/trunk.fix_757434 updated on 2011-04-14

2750. By Sam Spilsbury on 2011-04-14

Move the restacking of docks to *after* when the window is restacked X side,
it makes no sense to send the stacking request to stack relative to the
window which is going to go above the fullscreen window when it is
*not* above the fullscreen window, since that results in docks going just
above that, and then the window going above the fullscreen windows.

Also reset xwc every time we restack a collected dock relative to the normal
window since the stack is LIFO (eg collects in reverse, and so stacks in
3,2,1) to prevent the order of the dock windows getting inversed every time
the docks are restacked relative to some other window

Revision history for this message

Sam Spilsbury (smspillaz) wrote on 2011-04-14:

#

oops, need to remove the debugging code here

lp://qastaging/~unity-team/compiz/trunk.fix_757434 updated on 2011-04-14

2751. By Sam Spilsbury on 2011-04-14: Remove debugging code

Compiz

Merge lp://qastaging/~unity-team/compiz/trunk.fix_757434 into lp://qastaging/~unity-team/compiz/trunk

Commit message

Description of the change

Preview Diff

Subscribers