Clicking the title of a window is bringing a window underneath it into focus

[Andrew]

Binary package hint: gnome-session

TEST CASE:
1) Open a terminal
2) Doubleclick on the titlebar of the terminal to maximize the window
3) Open a folder
4) Pressing (X) on the folder closes the terminal (!), not the folder.

5) install version from maverick-proposed
6) relogin
7) redo 1-4 and verify that 4 is no longer a issue

Just recently, I have noticed with Karmic and my laptop that clicking on the window title bar focuses the wrong window. It happens mostly when I click and drag, expecting to move the window from one monitor to the other. Often the window is maximized.

In my setup, I have a laptop with an external monitor enabled via xrandr. The problem occurs with both my DVI and my VGA output. I put my laptop into standby when I leave work and wake it back up at home, so I switch between the monitors in one gnome-session.

My LnF is custom, using Human-Clearlooks and a custom Window Border I found on the gnome look site called "BlendedSmallDoubleRound".

It isn't 100% reproducible but does happen quite often. I never had this problem in Ubuntu pre-Karmic.

ProblemType: Bug
Architecture: amd64
Date: Tue Dec 8 09:31:22 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
Package: gnome-session 2.28.0-0ubuntu5
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-15.50-generic
SourcePackage: gnome-session
Uname: Linux 2.6.31-15-generic x86_64

[Andrew (andrew-rw-robinson)]

Oh, and I have visual effects turned off, so this is related to Metacity only, not Compiz.

[Foldarn (ascheel)]

I've seen this as well. I also have Compiz effects turned off. For me to replicate this easily, I need only maximize my Firefox window, Maximize a terminal window that was previously not maximized (I do so by double-clicking the titlebar), Alt-Tab back to Firefox, and if I double-click the titlebar or click the minimize button or click the normalize button or the close button, the click affects the previously active window, in this case the gnome-terminal. So if I minimize the Firefox window, it instead minimizes the gnome-terminal window. I moved the file .gconf/apps/metacity out of the way, rebooted, and it hasn't affected anything. If it matters, the metacity folder did not get recreated after reboot as I would have expected.

[cgrushko (carmi-grushko)]

Could also reproduce by Foldarn's instructions, on a Karmic upgraded from Jaunty. Using default Human-Clearlooks, no Compiz.

[Eugene Kirpichov (ekirpichov)]

This bug only started occuring to me in 9.10 (I don't remember whether it was an upgrade or a fresh install), things were OK in 9.04. I also have Compiz disabled. The bug is very annoying, especially when the wrong window gets closed :-| I'm starting to teach myself to first click on the title bar or on the window that I'm going to close or move in order to ensure that it gets the focus, but I don't (and shouldn't) always remember to do that.

[liam2 (cosinusoidaly)]

I think this is the same behaviour as https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/480981

[Alkis Georgopoulos (alkisg)]

I can confirm this. It started happening in 9.10 for me too, and it's still happening on my freshly installed Lucid.

It's rather annoying because the "lost clicks" randomly affect the applications below the focused window: they may e.g. close an application by hitting its [X] button, or they may even delete stuff by clicking on some Cut/Delete/Paste button, and the user may not even notice it, as the application where that happens isn't focused!

[Shane O'Connell (shaneoc)]

It seems like this only happens with certain themes... After switching my window borders to "New Wave" it seems like it's not happening anymore. It also doesn't happen when using compiz, even with themes that screw up metacity.

The original poster also mentioned that he uses multiple monitors, and so do I. The other posters haven't mentioned whether they do or not but maybe that's also required to see the problem.

Somehow it seems like the problem is some interaction between metacity and certain themes, including the default Human one, and possibly relating to using multiple monitors.

[liam2 (cosinusoidaly)]

This seems to fix the behaviour for me:

--- src/ui/frames.c.orig 2010-02-04 01:06:21.000000000 +0000
+++ src/ui/frames.c 2010-02-04 01:06:31.000000000 +0000
@@ -1429,7 +1429,6 @@
       event->button == 1 &&
       event->type == GDK_2BUTTON_PRESS)
     {
- meta_core_end_grab_op (gdk_display, event->time);
       return meta_frame_double_click_event (frame, event);
     }

I've reported this bug https://bugzilla.gnome.org/show_bug.cgi?id=608296 to the gnome metacity bugzilla too.

[Roman Yepishev (rye)]

I have exactly the same issue when running in dual-monitor set up in Lucid Lynx.
When I start grabbing one window to position it on another monitor I end up grabbing completely different window instead.
This happens for me in non-compositing mode (running nouveau) and this is quite irritating.

[Alkis Georgopoulos (alkisg)]

I haven't tried the proposed patch, I just want to note something I noticed today:

Maximized window underneath ⎽☐☒
  Non-maximized window on top ⎽☐☒

I tried to click on the close button of a not-maximized window. I saw the close button of the maximized window underneath it getting highlighted + clicked even though that button wasn't below the mouse!

So the mouse coordinates are translated relatively to the window on top, even though they take effect on the window behind.

[Alkis Georgopoulos (alkisg)]

I've manage to consistently reproduce it:
1) I have 2 windows open. One of them is "restored", i.e. not maximized neither minimized. The state of the other window doesn't matter.
2) I double click on the title bar of the restored window to maximize it (the problem doesn't happen if I click on the maximize button instead).
3) I press [Alt]+[Tab] to go to the second window.
4) I try to click/drag the second window from the title bar. Instead, the first window is clicked/dragged.

[Alkis Georgopoulos (alkisg)]

Heh, I've just noticed that the upstream bug description is essentially the same as the way I reproduced it. :)

[Gilles Gagniard (gilles-gagniard)]

Here is a very simple scenario to reproduce it on my box (lucid) ... Single monitor setup, reproducible whatever the theme (ambiance, radiance, new wave), using metacity and not compiz of course.

From an empty desktop freshly started, with a gnome terminal launcher in the upper panel :
- launch gnome terminal
- double click on title bar -> it's now maximized
- launch a new gnome terminal -> there's now the old maximized gnome terminal in the background and the new windowed gnome terminal in the foreground
- grab-and-move the title bar of the *new* windowed gnome terminal -> the *old* maximized one is unmaximized and moved instead of the new one

[Neural Simulation (remowilliams006)]

This "minor" bug is going to cause me to switch to some other operating system.

It isn't minor when I click on the close button of a window, and instead my O/S closes the window behind it. This behavior can literally cost me money (and has).

[Ioannis Ramfos (isr81)]

A simple workaround that can be used until this issue is fixed, is changing the default behaviour of double clicking on the title bar to something other than "Maximize" or Maximize Vertically", under System --> Preferences --> Windows (Titlebar action).

[Marc Reichelt (mreichelt)]

IMHO this bug should get a high priority, because it is possible for users to close windows behind the window they currently are seeing simply by pressing the (X) button - and this might destroy important work.
Here is a screencast of a scenario where this bug occurs:
http://marcreichelt.de/misc/ubuntu/bug_494096.ogv
Description:
1) Open a terminal
2) Doubleclick on the titlebar of the terminal to maximize the window
3) Open a folder
4) Pressing (X) on the folder closes the terminal (!), not the folder.

Would be great to see this fixed in 10.04 LTS :-)

[Hernando Torque (htorque)]

The upstream status is "Priority: High, Severity: critical" - there's a working patch attached but it's not yet committed (neither to metacity nor mutter).

[Lennart Hengstmengel (farenji)]

Still (or again?) present in 10.04.
This bug has affected me since a month or two, maybe longer, not sure. This is a nasty issue - multiple times I have closed a window that should not be closed, due to this bug. Very irritating. It also happens when I try to move a window. It is easily reproducable, every time. Why is it taking so long for the fix to make it into the repository?

Ubuntu 10.04, no compiz, dual monitor, Human-Clearlooks theme.

[John Lee (jjl)]

I'm just here to note the irony of the fact that in my browser (Chromium), clicking the icon on this bug tracker next to the text "This bug affects 28 people. Does this bug affect you?", in order to indicate that this bug affects me, causes a JS dialog to pop up in a position mostly off the LHS of my screen, where I can't read its contents. The dialog cannot be moved.

[Rob (dsmlover)]

Fixed in Ubuntu 10.10, great job!

[Alkis Georgopoulos (alkisg)]

Is a Lucid backport possible?

The bug is rated as critical, clicking on random points of the window underneath the active one can cause anything, from loss of data to security problems...

[Savvas Radevic (medigeek)]

There's a patch available at https://bugzilla.gnome.org/show_bug.cgi?id=599181 reviewed as sane.

[sdafin (sdafin)]

Hello!

This really needs to be fixed to Lucid.
I have this bug every Lucid install; at least 2 upgrades from 8.04 and 1 non upgrade
(one x86_64 and two x86, all with Intel gfx).

[Michele Bonera (michele-bonera)]

The bug is still present in Lucid Lynx and is very very annoying.
Please: release a backport for Lucid!

[Martin Pitt (pitti)]

Subscribing ubuntu-sponsors; a patch is available, just needs to be backported to lucid.

[Scott Moser (smoser)]

I put together a branch with the patch for easier merging for someone with rights to commit, and put a build in my ppa of 'metacity - 1:2.30.1-0ubuntu1.1~ppa0' (https://launchpad.net/~smoser/+archive/ppa).

If someone subscribed here could test that build and report back, it would make it even more straight forward for the sponsor to pull the branch and get the fix into lucid. Anyone able to do that?

[SapphirePaw (sapphirepaw)]

Lucid, Ambiance, visual effects None, metacity-1:2.30.1-0ubuntu1.1~ppa0 (logged out & back in after upgrade): now works on the correct window, following instructions of anyone on this bug. It used to fail every time with steps from above. On the PPA version, drags and clicks to the Close/Min/Max buttons all go to the expected window, where the mouse is.

tl;dr: works for me 100%, where it used to fail 100%.

[SapphirePaw (sapphirepaw)]

Additional note: reproduction on the non-PPA version is no longer 100% reliable for me. It worked best with Synaptic opened in the background (it opens maximized; terminal #2 failed on 2 of 2 trials), but opening Firefox maximized didn't expose the bug (1 trial). Still, repeatedly opening gnome-terminal, maximizing it, and repeating failed when the click on terminal #4's titlebar brought terminal #3 into focus instead (1 trial).

With this new knowledge, I retested the PPA version. I couldn't get it to fail, even opening firefox or synaptic, followed by 13 terminals (1 trial each). Still working for me, then.

[cheater (cheater00)]

This is a critical issue which can lead to:

1. security compromise: a process is running in a terminal, which can get closed by a mis-click. This is now open to being spoofed by someone while you're gone, to e.g. steal your password. Alternatively, let's say it was a firewall, which is now removed.
2. lost work (there are comments here that mention this has cost people considerable amounts of money)
3. instability (you disable an important part of the system)
4. data corruption (data is overwritten because it goes into the wrong window as per one of the comments above)

There has been a patch for this *critical* issue over a year now (!) and there is a fix in 10.10 since the very release. There is absolutely no reason for the harsh wait until 29/07/2011. Taking 5 months for something that takes 5 seconds, when there's a critical issue on hand, is not the way forward. The alternative of poisoning your system with PPA's or self-compiled software is not acceptable. Switching to a non-LTS release is not a solution either. Please fix immediately, there really is no reason not to.

[Etienne Goyer (etienne-goyer-outlands)]

Tested, and I confirm Scott's PPA package of metacity fix the bug for me here. Thanks Scott!

[Michael Vogt (mvo)]

I added a test case for the SRU but I'm not in the best position to judge if that are ideal test-case instructions. Please update if appropriate, I will upload to lucid-proposed now.

[Chris Coulson (chrisccoulson)]

This was uploaded to lucid-proposed on 15th Feb. It just needs approving ;)

[Michael Vogt (mvo)]

This is in lucid-proposed now (twice actually because the initial upload was not mentioned here).

[Martin Pitt (pitti)]

Accepted metacity into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Etienne Goyer (etienne-goyer-outlands)]

Michael's test-case is all good, except it should refer lucid-proposed.

So, I tested the package in lucid-proposed, and it work as expected. +1 from me!

[Alkis Georgopoulos (alkisg)]

The metacity from lucid-proposed works fine here.

$ dpkg-query -W metacity
metacity 1:2.30.1-0ubuntu1.1

[Launchpad Janitor (janitor)]

This bug was fixed in the package metacity - 1:2.30.1-0ubuntu1.1

---------------
metacity (1:2.30.1-0ubuntu1.1) lucid-proposed; urgency=low

  * Fix LP: #494096 - backport upstream commit from GIT to stop confusing
    GDK's grab tracking
    - add debian/patches/14_gdk_grab_tracking_fix.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Fri, 04 Feb 2011 17:41:14 +0000