I can confirm this. It happens quite often since 2.15.34.
Right clicking the window title of the window that doesn't get focus seems to be the easiest way to 'fix it'

I've seen it a couple times as well, though I had suspected stuck grabs or something in other apps; I have no clue what the cause is (and am not sure it's in metacity; it'd be great if someone could rule out other apps by e.g. verifying that this bug doesn't occur after a day or two of usage with metacity-2.14.x).  I'll try to find some time to look into it soon since this is extremely annoying.  (Alt-tab seems to be the easiest 'fix' for me)

According to the Ubuntu bugreport this doesn't happen with spiftacity 2.13.89

Are you sure?  The Ubuntu bugreport said:
  'Seems to be a bug in metcity since "spiftacity --replace" seems to fix it.'
Alt+tab or right click on the titlebar also fix it.  The commenter in that bug didn't say anything about running for a day or two after running spiftacity.  (btw, what in the world is spiftacity, other than obviously a window manager and likely a fork of metacity?)

spiftacity seems to be plain metacity with compositor enabled, only a fairly old version in Ubuntu ;)

I'll report back after talking to him... but as he was able to reproduce it very fast while trying different possible solutions I would assume that he tried long enough.

I have Debian Etch and I have the problem frequently. The metacity version is 2.14.5.

I have Evolution open, an email message window, two Gnome xterminals, two Firefox windows and Synaptic. If I click on the taskbar icons to switch, there is a higher chance of a hang after the Firefox window is used. It also happens between other apps, but this seems to happen the most with Firefox.

.gconf/apps/metacity/general/%gconf.xml is:

<?xml version="1.0"?>
<gconf>
        <entry name="theme" mtime="1156985776" type="string">
                <stringvalue>Clearlooks</stringvalue>
        </entry>
        <entry name="focus_mode" mtime="1157424044" type="string">
                <stringvalue>click</stringvalue>
        </entry>
</gconf>


  

In Fedora Devel (FC6) this error is hit many times during the normal course of using sylpheed.  Each time you switch message folders or a folder with new/unread messages and then select SummaryView, the SummaryView becomes selected but nothing has the focus.  You have the to select the drag bar at the top of the window to gain the focus.  This also happens in the Compose window when the window first opens.  It also happens when you reply to two messages (have two compose windows open) and cut-n-paste contents from one to the other.

Sylpheed seems to be hit hard because to uses separate windows heavily.

metacity-2.16.0

I downgraded and have been running with metacity 2.14.5 for a couple of days now. I can't reproduce with this version, so for me at least, the bug seems to be in metacity > 2.15.34.
I'll keep using this version for a few days more to be sure.

It's metacity bug. to reproduce:
1. start a gtk+ program (I've used epiphany)
2. set "select windows when the mouse moves over theme"
3. roll up/down window (double click on title bar - "Roll up" in window preferences must be set)
4. try to open something (File menu, panel menu)
voila! triggered. (use alt+Tab to regain focus)

small screenshot attached ("File" menu not pulled down)

Created attachment 72430 [details]
broken focus behaviour

I cannot reproduce with the actions in comment 9.  :-(

If you run metacity in a terminal (or restart it with 'metacity --restart') and then duplicate the bug, are there any warning messages printed out?

@ comment 11: try to roll up/roll down a window a few times, it's 100% reproducible.

@ comment 12: there are no messages at all. dead calm. Can we debug it somehow?

I see these warnings, although I've seen the focus problem more often than the warnings occur:

Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

Window manager warning: Got a request to focus 0x4e0004d ((Untitled)) with a timestamp of 0.  This shouldn't happen!

The only focus related change is introduced in 2.15.32 (from NEWS):

- fix an uninitialized-usage bug with net_wm_user_time that breaks
  focus with new windows (Vytautus)

Appears to be a stuck grab, due to the use of our dear friend CurrentTime[1].  This bug has _always_ existed in the code.  However, the patch from bug 126497 apparently made it _much_ easier to trigger this race condition; I can trigger this bug about 5-10% of the time using Fryderyk's instructions in comment 9 with a metacity version that incorporates the patch from bug 126497 and I do not seem to be able to trigger the bug with older versions of metacity (though that doesn't mean that others can't).

I've cooked up a patch that seems to fix the problem for me, but I couldn't trigger it as easily as some of you.  It's possible there's more than one bug here as well.  So, I'll attach the patch here.  Can I get a few people to test it?

[1] CurrentTime is just so wonderful.  It provides hours of entertainment, repeating certain fun-filled steps (e.g. close window A via X button so that window B is under the mouse and quickly activate window C, reopen window A and position it just right, close window A via X button so that window B is under the mouse and quickly activate window C, reopen window A and position it just right...) and repeating such steps *hundreds* of times trying to trigger certain race conditions.  Too bad our uses of CurrentTime and meta_display_get_current_time() are being eradicated from the code, as it means such entertainment won't be available anymore (see bug 152000 for the most exciting time this kind of bug provided).  But, there's still quite a few more left before we run out of this fun.  What are the odds we learn our lesson and audit the code and just remove them pre-emptively?

Created attachment 72462 [details] [review]
Delete two uses of meta_display_get_current_time() and use valid timestamps instead; seems to fix the bug for me so far

Removing all meta_display_get_current_time in principle is pretty mechanical right? (Everywhere it occurs, remove the call, add a function argument, then fix compile errors up the call stack until you have an event to get the time from)

The patch certainly looks correct whether it fixes this bug or not...

Yep, and probably a good task for someone wanting to contribute to metacity; filed as bug 355180.  :)

Applying Elijah's patch fixes the problem. no matter how hard I try, I can't reproduce it anymore. Thanks Elijah for solving it so fast!

Original comment has a link to the Ubuntu bug report about the same issue; there's also one in Red Hat bugzilla at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204519.  I've asked the reporters and commenters on those two bugs to also test to see if anyone can trigger any similar issues or whether it was just this one problem affecting everyone.

Given the 4 separate confirmations that this patch seems to fix the bug (one by Fryderyk, two in Red Hat bugzilla, and one in Ubuntu whatchamacallit), I'm marking as fixed.  I'll roll a 2.16.1 release (or get someone else to) tomorrow with this fix.

I've uploaded a patched package to edgy, I'll comment to the bug according to the launchpad comments on the patched version

*** Bug 355401 has been marked as a duplicate of this bug. ***