New windows placed with focus behind fullscreen window

Bug #153676 reported by Bogdan Butnaru on 2007-10-17
40
This bug affects 2 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Low
Robert Ancell
Nominated for Hardy by Paul
Nominated for Intrepid by Paul
Nominated for Jaunty by Paul

Bug Description

When a new window is created and you have a fullscreen window the new window gets focus but is still hidden behind the fullscreen window.

Steps to reproduce:
    1. Open gnome-terminal
    2. Make the terminal window fullscreen (F11)
    3. Open a new terminal window with Ctrl-Alt-N

Result:
A new window is (correctly) opened, it is given focus (correctly), but it's behind the fullscreen window.

Expected:
The new window should be on top of the stack or at least not get focus.

Note that this happens for _every_ kind of new window that should appear on top, including dialogs opened by the fullscreen window, which is the most annoying thing (think of Save dialogs, exit confirmations, etc).

Related branches

Bogdan Butnaru (bogdanb) on 2007-10-17
description: updated
Bogdan Butnaru (bogdanb) wrote :

I'm not so sure. I have none of the symptoms described there. Also, there is absolutely no corruption visible, it's as if Compiz thinks that's what's supposed to happen.

By the way, I have the exact same behavior on firegl and intel drivers, on two different computers. On the ATI card Compiz runs on Xgl, while the intel machine doesn't eves have Xgl installed, so I guess we can exclude driver issues here. (Unless someone can't reproduce this at all.)

Bogdan Butnaru (bogdanb) wrote :

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?

Bogdan Butnaru (bogdanb) wrote :

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)

     updateWindowAttributes(w,CompStackingUpdateModeAboveFullscreen) followed by
     updateWindowAttributes(w,CompStackingUpdateModeNone)

However, when the user initiates a window move by dragging its title bar, the calls are:

     updateWindowAttributes(w, CompStackingUpdateModeAboveFullscreen)
     raiseWindow(w)
     updateWindowAttributes(w, CompStackingUpdateModeNone)

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.

Bogdan Butnaru (bogdanb) on 2007-12-01
Changed in compiz:
assignee: nobody → bogdanb
distefam (distefam) wrote :

I am having this issue on the eeePC and it's quite annoying because I like to run at full screen all the time because of the small screen. I saw that there is a fix, by altering the code. I've never done that before but I would be willing to and I have some experience in programming. What steps do I have to follow exactly? I know I would have to download the compiz source, but for which package?

Bogdan Butnaru (bogdanb) wrote :

De-assigning myself. I fixed this, but I have no idea how to send the fix in.

Changed in compiz:
assignee: bogdanb → nobody
Bogdan Butnaru (bogdanb) wrote :

You have to download the source to compiz, make a small change, compile and install it.

To download:
$ apt-get source compiz

The change: Find in the file src/window.c these lines:

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

And change the line that starts with aboveFs to:

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

Then you need to compile it:

$ sudo apt-get build-dep compiz
$ ./configure
$ make

(You need to be in the "root" directory of the package, which gets created by "apt-get source" in the first step. It's the one above the src directory. If you compile it several times, you don't need to run the first command each time; once is enough.)

Then you need to install it, which is actually the most annoying part. You just run

$ sudo make install

and it puts the new compiz in /usr/local/bin. That's easy enough, but you have to modify the /usr/bin/compiz file, which is a script, to run yours instead of Ubuntu's. If you know a tiny bit of scripting it's easy though. The annoying thing is that on every update of compiz the file gets re-written. I just keep a copy somewhere and replace it when that happens, but I'm sure there must be a better way...

(Note that in the package installed by Ubuntu the executable is called "compiz.real", and "compiz" is a script that runs it with some arguments. The compiled one has the executable called "compiz" and no script (that I can see). I suppose you could play with the ./configure script, if you're so inclined.)

Tim O'Callaghan (timo-linux) wrote :

It does the same for the default livecd screen setup with the AMD64 Ubuntu 8.04 alpha on my laptop with an Nvidia Chipset.
Using the gnome-appearance-properties tab, and switching from normal back to compviz effects seems to work for me.

Changed in compiz:
importance: Undecided → Low
Travis Watkins (amaranth) wrote :

The second half of this bug will be fixed in the next upload of compiz.

Basilio Kublik (sourcercito) wrote :

Hi there
you report this issue some time ago and hasn't been any activity for a while, so i was wondering if this is still an issue for you under the development version of Ubuntu, Hardy Heron.

Thanks in advance

Changed in compiz:
assignee: nobody → sourcercito
status: New → Incomplete
Bogdan Butnaru (bogdanb) wrote :

Yes, it still happens in a just-updated Hardy.

I have fixed this several times, and I sent patches to some devs but have been ignored. I think the patches are stale now, but it's easy to fix. If any of the devs contacts me I can send another one. (The fix is described above, anyway.)

Changed in compiz:
assignee: sourcercito → nobody
Travis Watkins (amaranth) wrote :

Part 2 is fixed in Ubuntu, your fix for part 1 is not acceptable upstream.

Changed in compiz:
status: Incomplete → Confirmed
Bogdan Butnaru (bogdanb) wrote :

OK, I just checked. The fading-when-dragged-windows part is gone.

But the most annoying one is the first part. Do you have any more info from upstream on what's wrong with my proposed fix?

Remember that not only are windows hidden under full-screen ones, but they also get the focus, which is doubly wrong.

summary: - full-screen windows sometimes hide windows that should be above them
+ New windows placed with focus behind fullscreen window
Changed in compiz (Ubuntu):
status: Confirmed → Triaged
Changed in compiz (Ubuntu):
assignee: nobody → Robert Ancell (robert-ancell)
description: updated
Travis Watkins (amaranth) wrote :

This bug should be fixed in the "0.8.3" git snapshot we have in the compiz PPA, can you confirm that is the case?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.8.3+git20090914-0ubuntu1

---------------
compiz (1:0.8.3+git20090914-0ubuntu1) karmic; urgency=low

  * Pre-Version of the upcomming 0.8.4 bugfix release
    - fixes crashes LP: #268683, #284362, #346391, #351878, #352037, #380338
    - fixes crashes on 64bit arches due to issue in va_list use
    - fixes at least some of the doPoll/eventLoop crashes reported in
      LP: #131679, #145360, #279820
    - likely fixes crashes LP: #340428 and #360643
    - fixes placing of dialogs (e.g. PolicyKit) behind currently focused
      window (LP: #165161)
    - fixes placing of new windows behind fullscreen window (LP: #153676)
    - fixes wobbly bouncing near panel and screen edges (LP: #153374)
    - screenshot plugin now saves to the correct desktop directory by default
      (LP: #175116)
    - lowering a window now activates the topmost window, unless
      click-to-focus is off (LP: #122507)
    - fixes inconsistent icon sizes in switcher, ring, shift, staticswitcher
      plugins
    - fixes some memory leaks
    - texture compression is now off by default due to texture quality issues
    - ported KDE4 window decorator to KDE 4.3
  * debian/control:
    - add versionized dependency on compiz-wrapper from
      compiz-core

compiz (1:0.8.3+git20090907-0ubuntu1~ppa1) karmic; urgency=low

  * new git snapshot

compiz (1:0.8.3+git20090904-0ubuntu1~ppa2) karmic; urgency=low

  [ Travis Watkins ]
  * debian/compiz-manager:
    - set COMPIZ_PLUGINS to plugins we want to always have enabled

  [ Saïvann Carignan ]
  * debian/compiz-gnome.gconf-defaults: Re-enable desktop switching by
    default as it has been fixed by appropriate GNOME schemas. (LP: #414170)

compiz (1:0.8.3+git20090904-0ubuntu1~ppa1) karmic; urgency=low

  * new git snapshot:
    - fixes segfaults on 64bit arches
    - warning fixes
    - avoid adding core twice

compiz (1:0.8.3+git20090831-0ubuntu1) karmic; urgency=low

  [ Michael Vogt ]
  * new git snapshot with fixes from 0.8 branch:
    - fix stacking below problem with the polkit1 dialog
    - fixes doPoll() crash (LP: #131679)
    - many more bugfixes
  * debian/control:
    - add "Provides: x-window-manager" to the compiz package
      (LP: #364242)

  [ Robert Ancell ]
  * debian/control:
  * debian/rules:
    - Build a compiz-dbg package (LP: #420321)

 -- Michael Vogt <email address hidden> Mon, 14 Sep 2009 09:39:42 +0200

Changed in compiz (Ubuntu):
status: Triaged → Fix Released
Bogdan Butnaru (bogdanb) wrote :

Hi Travis, can you post a link to that PPA?

I'll be updating to Karmic any time now, and I'll take a look.

Travis Watkins (amaranth) wrote :

No need now, the fixed package is in karmic.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers