Since I fully resynced with yesterdays rawhide I now regulary lose the cursor/ability to type in *any* application on the desktop. I can still focus a window (ie the title bar changes it's color) but I cannot type anything in the terminal or in gedit. Also when focusing a window I don't get any cursor (in gedit it completely disappears, in the terminal the cursor is displayed as "unfocused" i.e. as an unfilled rectangle). Also the menus can be selected and get highlighted but the actual menu popup doesn't appear. Opera is affected too so this doesn't seem to be limited to gtk2 apps. Risizing a window (or at least clicking a border) fixes the problem until it reappears a while later. These are the package versions I have installed right now: metacity-2.15.34-1.fc6 gtk2-2.10.2-3.fc6 xorg-x11-server-Xorg-1.1.1-30.fc6 kernel-2.6.17-1.2586.fc6 I'm not sure if metacity is the right component for this bug so feel free to reassign if necessary.
Right, the same here. In general, one manages to recover focus by closing some window by clicking the [x] button or by opening a new windows. Even menu buttons often get only highlighted, but no menu opens. This happens on a current "rawhide" desktop. The issue is probably 2-3 days old. Btw, I have tried a current "Ubuntu" development live CD, and the issue there shows up identically. So, it's not "Fedora" specific.
sounds like either the X server or metacity is getting confused about the keyboard focus, probably metacity.
Me too. My current "fix" is to hit Alt-Tab twice (which will select a different window, and then back) to restore focus.
*** Bug 205074 has been marked as a duplicate of this bug. ***
(In reply to comment #2) After downgrading to "metacity-2.15.5-6.1" of "FC6T2", all focus weirdness stops. It is thus clearly not the "X" server but rather the window manager which is to blame.
No need to go that far. I verified that 2.15.21-1.fc6 works (I lifted the old binary RPM from Brew archive). Unfortunately, no releases between .21 and .34 were packaged, so I cannot bisect further.
Sure, but in general, older "rawhide" packages are not accessible in most cases once they have got supplanted by the latest version - in this case the broken one. A clear advantage for Red Hat employees ;) I guess the best is to simply archive all packages released between test releases on my hard disk.
Pete, there were no releases between 2.15.21 and 2.15.34. Metacity does not believe in consecutive release numbers.
Works for me again after upgrading to "metacity-2.16.0-1.fc6".
Thats odd, since there were no relevant changes between 2.15.34 and 2.16.0
I updated to metacity-2.16.0-1.fc6 (via yum) and rebooted (to fixed the NFS problems): The problems seems more prevalent. I hit it with the first use of gnome-terminal. It's still happening with Sylpheed (although double-clicking does work). Sylpheed seems to be hardest hit because of multiple windows (possibly being created anew when switch message folders).
The problem with gnome-terminal happens when gnome-session starts gnome-terminal sessions. Once you work around the focusing problem by clicking the blue drag bar at the top, none of the remaining gnome-terminal windows have the problem.
I can confirm that the problem gets worse with metacity-2.16.0-1.fc6
Here is an upstream bug that may be relevant: http://bugzilla.gnome.org/show_bug.cgi?id=354422
Question for people who have seen this: what settings do you use? focus-follows-mouse, raise-on-click, etc?
Ubuntu bug: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/57344
$ gconftool-2 -g /apps/metacity/general/focus_mode sloppy $ gconftool-2 -g /apps/metacity/general/focus_new_windows smart $ gconftool-2 -g /apps/metacity/general/auto_raise true $ gconftool-2 -g /apps/metacity/general/auto_raise_delay 687 Often affected here are Emacs, xterm, Sylpheed, Firefox.
$ gconftool-2 -g /apps/metacity/general/focus_mode sloppy $ gconftool-2 -g /apps/metacity/general/focus_new_windows smart $ gconftool-2 -g /apps/metacity/general/auto_raise false
focus_mode = click focus_new_windows = smart auto_raise = false
Actually using the same troublesome settings as in comment #18: focus_mode: sloppy, focus_new_windows: smart, auto_raise false.
There's a patch in http://bugzilla.gnome.org/show_bug.cgi?id=354422 that should fix this; it was a race condition that always existed in metacity but became much easier to trigger with the patch applied for upstream 126497. Could people test with that patch applied and verify whether that fixes the bug or whether there might be more than one bug here? It seems to fix it for me, but I can reproduce very often at all...
er, that should be *can't* reproduce very often at all...
I ahve applied that patch to rawhide - it should show up tomorrow. In the meantime I have put up the new packages here: http://people.freedesktop.org/~sandmann/metacity-2.16.0-2.fc6/ Of course testing is appreciated. And thanks Elijah for providing the patch.
I installed 2.16.0-2 from comment #23 and sylpheed no longer suffers from this problem. Thanks.
So far it seems as if 2.16.0-2 fixes the problem indeed. I haven't seen the symptoms since I installed it.
Alright, thanks for testing. Closing this bug.
I see this for gnome-terminal and firefox still.... % rpm -q firefox gnome-terminal metacity firefox-1.5.0.6-12 gnome-terminal-2.16.0-1.fc6 metacity-2.16.0-1.fc6
caillon: Upgrade, dude. See comment 23-25, which says it seems to be fixed in metacity version 2.16.0-*****2*****.fc6 (well, minus the stars used for emphasis). ;-)
I had forgotten about the freeze, so the packages didn't actually show up in rawhide. I have asked rel-eng to move them now though, so they should show up tomorrow.
metacity-2.16.0-2.fc6 fixed this for me as well. I didn't have the follow-up problem for which Steven cloned this bug into bug 206263 -- despite the pointer hardware acting funny on this D610.