Comment 3 for bug 153676

Hello! I've done a bit of hacking through Compiz' sources, and I think I found the reason for the first problem.

As far as I could follow the process, Compiz calls updateWindowAttributes() on newly-created windows, with the stackingMode argument set to CompStackingUpdateModeInitialMap. This function is supposed to set the window's stacking, among other things. For instance, at one point it runs:

    if (stackingMode != CompStackingUpdateModeNone)
    {
 Bool aboveFs;
 aboveFs = (stackingMode == CompStackingUpdateModeAboveFullscreen);
 mask |= addWindowStackChanges (w, &xwc, findSiblingBelow (w, aboveFs));
    }

Which raises the given window on top of everything if the stacking mode is CompStackingUpdateModeAboveFullscreen. So newly-created windows are placed below full-screen ones, because they're not mentioned in that test. This might seem like a good idea, except that they're given focus (don't know where), which means that input would go to a window that's not visible (bad thing). Also, this is highly counter-intuitive (for instance, starting Firefox's download manager with FF in full-screen appears to be not working).

I changed the snippet above to contain

 aboveFs = (stackingMode == CompStackingUpdateModeAboveFullscreen)
   || (stackingMode == CompStackingUpdateModeInitialMap);

and now the stacking is the way I'd expect it. Does anyone think it can break something that way?