Description of problem:
In the "Window Preferences" program I have selected "Select windows when the
mouse moves over them".
This works (for a while) but every day for the last 5 days at some point not too
far into the workday it reverts back to click-to-focus. Needless to say, for
someone who has become very used to using point-to-focus every day for the last
5+ years it can really end up confusing (and dangerous! I almost typed a root
password in an IM window because I was expecting focus to follow the mouse)
I have not yet determined what program or behavior (if any) trigges the
reversion from point-to-focus to click-to-focus. If I return to the Window
Preferences program, deselect "Select windows when the mouse moves over them",
click Close, then return to Windows Preferences and re-select "Select windows
when the mouse moves over them" it still persists in using click-to-focus.
If I log out and log back in then it will return to point-to-focus until it
triggers again and I am back to click-to-focus.
Version-Release number of selected component (if applicable):
It has happened every login session for me so far, so it is consistently
recurring, but I haven't yet figured out what it is that triggers it.
Steps to Reproduce:
1. Select point-to-focus behavior
2. Use the desktop like normal. Programs I have used before seeing this
behavior are: gnome-terminal, Firefox, Evolution. Applets I have loaded (in
addition to the out-of-the-box default configuration): Tomboy Notes, Rhythmbox
Applet, the Weather Applet, Rhythmbox, and Gaim.
I don't know if the loaded program set impacts this behavior or not. If I
narrow it down any, I will post an update to this bug.
This system is a fresh install of FC5 and I cleared all of the dotfiles from my
home directory before logging in, so all of my Gnome desktop/user settings were
created from scratch from the FC5 defaults. I then made one or two adjustments,
including in the Window Preferences control.
Okay... I just noticed an odd aspect of this.
If I move the mouse from a focused window to a new window the focus still does
not change (as indicated by the title bar color) but the mouse scrollwheel will
scroll the window that the mouse is now pointing to.
However, if I type the characters are sent to the first window (which still has
the focus according to the title bar coloring).
Okay... I have noticed some new behavior related to this...
One of the other preferences I changed was the window Movement Key from Alt to
Super. I have used Super for moving windows for a long time.
Friday, the Super key stopped working to allow me to move windows. Any attempt
to move windows with the Super key pressed down behaved exactly as if I wasn't
holding Super down. I tried logging out and back in a number of times but I
could not get it working again. So, I switched back to having it use Alt, the
Alt was working just fine and I noticed that while Alt was selected for that
function then I did not experience the window focus problem I originally reported.
This morning it occurred to me that I should see if the Super key would begin
working after a reboot. I rebooted the system, reselected Super and I could use
it to move windows again! At this moment the Super key is still allowing me to
move windows but I have experienced the window focus problem again.
I don't know what relation the window movement key selection might have to
point-to-focus but at this point it seems like there might be one.
I, too, am seeing this; same versions.
One work-around that's easier than logging out (but not pretty nonetheless) is
to just kill Metacity, which causes gnome-session to restart it.
I encountered the point-to-focus failure with the Alt window movement key
selected. It now appears that it may be entirely unrelated to the movement key
I'm glad I'm not the only one seeing this. Wil, I will try killing metacity.
I'm seeing this on x86_64 as well. Metacity version 2.14.0-1
I am seeing this as well. Very annoying! The trigger for me, is to launch k3b.
Then focus follows mouse no longer works. Thanks for the kill metacity idea!
Yup, seen here.
Seeing the same problem. Has caused data loss due to typing commands in wrong
window. Between this problem, the new strict-focus-approximation "feature" and
the long standing debate re: mouse/sloppy focus mode I am about convinced to go
to KDE. Everytime I upgrade or apply rpm updates I have to fight for hours to
get metacity usable on any RedHat based distro.
My reproducer machine updated to metacity-2.14.3-1.fc5.1 and I have yet to see
the problem again. Hopefully it was fixed for good! :)
(In reply to comment #8)
> Seeing the same problem. Has caused data loss due to typing commands in wrong
> window. Between this problem, the new strict-focus-approximation "feature" and
> the long standing debate re: mouse/sloppy focus mode I am about convinced to go
> to KDE. Everytime I upgrade or apply rpm updates I have to fight for hours to
> get metacity usable on any RedHat based distro.
Discovered the problem was reproducible. When running kde-pim/korganizer a
pop-up reminder would break metacity point to focus until metacity was restarted.
Since recent update everything has been fine.
Great work. Also found that metacity is now built with the feature to stop
"raise on click", accessible with gconf-editor. Metacity frustrations are all
gone with the latest release build.
I, too, have not seen any more focus problems with the recent metacity update.
I'm seeing this consistently with metacity-2.14.0-1. Only Firefox and
gnome-terminal running. Not sure if it's relevant, but this system was upgraded
to FC 5 (rather than a fresh install). Attempting upgrade to