lp:~compiz-team/compiz/compiz.fix_1088399

Created by Sam Spilsbury and last modified
Get this branch:
bzr branch lp:~compiz-team/compiz/compiz.fix_1088399
Members of Compiz Maintainers can upload to this branch. Log in for directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Compiz Maintainers
Project:
Compiz
Status:
Merged

Recent revisions

3526. By Sam Spilsbury

Fix compile error

3525. By Sam Spilsbury

Fix typo and collapse if statments

3524. By Sam Spilsbury

Merge lp:compiz

3523. By Sam Spilsbury

Fix typo in acceptable type calculation

3522. By Sam Spilsbury

Merge lp:compiz

3521. By Sam Spilsbury

Ensure that we never get a BadWindow due to the sibling in a ConfigureWindow.

Issuing a ConfigureWindow request with a sibling parameter that refers
to a sibling that's actually destroyed server side results in a BadWindow
error, and causes what we might think is a correct ConfigureWindow request
to fail. This would cause even more problems because we had marked
the request as succeeding, and adjusted serverWindows appropriately,
which would cause further restacks to rely on the invalid internal state.

Unfortunately, this is effectively a race condition between the client and
the server. We receive our events and are racing the server to not
destroy the window internally before we get a chance to issue a
ConfigureWindow request relative to the destroyed window.

Because of that, we need to hold a server grab during the period in which
we check if the sibling window is still valid server side and when
we issue a ConfigureWindow request. If it is valid, then we can guaruntee
that the server will process the request relative to the sibling window,
and if not, we can select another sibling as appropriate.

Adjusted the API such that any function which looks for an appropriate sibling
or any function which calls XConfigureWindow with the sibling parameter
set requires a server grab to be active (by virtue of the fact that they
accept a const ServerLock &).

The only implicit contract between clients now is that the client must
obtain the sibling window either by using one of the designated functions
to do so which requires a ServerLock, or that the client holds a server lock
and while it holds the ServerLock, it calls XGetWindowAttributes or
XGetGeometry to check if the sibling window is valid.

configureXWindow was split into configureXWindow and
restackAndConfigureXWindow. The latter requires a server lock, the former
will warn about this potential race condition if you attempt to
restack a window using it.

Passing tests:

[ RUN ] CompizXorgSystemStackingTest.TestCreateRelativeToDestroyedWindowFindsAnotherAppropriatePosition
[ OK ] CompizXorgSystemStackingTest.TestCreateRelativeToDestroyedWindowFindsAnotherAppropriatePosition (55 ms)

(LP: #1088399)

3520. By Sam Spilsbury

Scratch that - found an accurate reproducer for the problem.

We can splice the CreateNotify -> Restack -> Destroy in between
the MapRequest and the MapNotify by holding a server grab while we do:

MapRaised w2
Create w3
Destroy w2

3519. By Sam Spilsbury

Added test case for restacking relative to destroyed windows.

Under TDD methodology, this should be a failing test, however it isn't,
because (LP: #1088399) is a race condition between when we receive
MapRequest for a client and map the window and then later between that, destroy
it and receive a CreateNotify for a new window on top of it, and restack
the new window on top of the not-yet-mapped, but-also-destroyed window

3518. By Sam Spilsbury

Actually instantiate the CCSSetting test cases, change ccsSet* to provide more detailed information on what actually happened during the set operation. Fixes: https://bugs.launchpad.net/bugs/1063617.

Approved by Daniel van Vugt, PS Jenkins bot.

3517. By Daniel van Vugt

Const'ify the methods of CompWindow where possible. I think this covers all
candidates except for:
   1. sizeHints() - we need to fix LP: #925867 first.
   2. other methods that return references to ints, because no corresponding
      "set" method exists yet.
As those are logic changes, I would prefer to deal with them separately.

Approved by PS Jenkins bot, Sam Spilsbury.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:compiz/0.9.9
This branch contains Public information 
Everyone can see this information.