For now, new selection objects are only created in ProcSetSelectionOwner()
when dixLookupSelection() can't find the requested one (returns BadMatch).
When somebody's trying to listen on a not-yet existing selection, via
XFixesSelectSelectionInput() -- XFIXES:SelectSelectionInput message -- he's
also getting BadMatch. This isn't neccessarily completely wrong, the spec
doesn't really tell anything about those situations (it doens't tell anything
about selection's lifetimes, just their ownerships). But there are real-
world clients not expecting an error here and crashing - the problem popped
up just recently, due to a necessary security fix (remote memory corruption
plus XACE missing to catch SelectSelectionInput) that alread went unnoticed
for far too long (*1).
So, it's better being polite and interpret the spec in the way that any
potential selection exists as soon as it's used by someone. (in fact, they
never get deleted anyways, just cleared).
XACE consumers get properly notified by the new Selection object creation
(eg. SElinux is attaching it's private data to it). And all callers already
prepared to get a cleared Selection object, because that's always been a
perfectly normal situation - Selection objects never get removed again,
just cleared.
*1) 601fd0fd84
X-Fixes: 601fd0fd84
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
52f11ad5c2