However, the call to raiseWindow(w) contains a call that looks like addWindowStackChanges (w, &xwc, findSiblingBelow (w, FALSE)), which actually causes the window to be re-stacked _below_ any fullscreen windows. As I mentioned in bug #162762, I don't see any reason why that FALSE shouldn't be TRUE, so using the fix I proposed there should fix part 2 of this bug, too.
Alternatively, if there is a very good reason why raiseWindow does things the way it does now, probably the raiseWindow should be replaced.
I've just did some more testing, and it seems the second part of this bug is caused by the same issue that causes bug #162762.
When the user initiates moving a window using the Alt+drag combination, compiz calls (among other things)
updateWind owAttributes( w,CompStackingU pdateModeAboveF ullscreen) followed by owAttributes( w,CompStackingU pdateModeNone)
updateWind
However, when the user initiates a window move by dragging its title bar, the calls are:
updateWind owAttributes( w, CompStackingUpd ateModeAboveFul lscreen) owAttributes( w, CompStackingUpd ateModeNone)
raiseWindow(w)
updateWind
However, the call to raiseWindow(w) contains a call that looks like addWindowStackC hanges (w, &xwc, findSiblingBelow (w, FALSE)), which actually causes the window to be re-stacked _below_ any fullscreen windows. As I mentioned in bug #162762, I don't see any reason why that FALSE shouldn't be TRUE, so using the fix I proposed there should fix part 2 of this bug, too.
Alternatively, if there is a very good reason why raiseWindow does things the way it does now, probably the raiseWindow should be replaced.