GNOME Bugzilla – Bug 149589
Race in focus window choice
Last modified: 2004-12-22 21:47:04 UTC
While trying to test things for bug 118372, I ran across a weird bug which only happens for click and sloppy focus modes (i.e. not for mouse focus mode). It appears that choice of focus window from the _NET_ACTIVE_WINDOW message and the choice of focus window from default_focus_window caused by a _NET_CURRENT_DESKTOP are fighting over which window to focus. This is sometimes causing flickering and causing the _NET_ACTIVE_WINDOW focus choice to be overruled when it shouldn't be. This isn't 100% reproducible. It seems to be not that difficult to reproduce (given 10 or so tries) if Mozilla (version 1.7.2 here) is one of the windows in the workspace, and really hard to reproduce otherwise (though I did reproduce it numerous times even without it to make sure it wasn't a Mozilla issue of some kind). The basic steps to duplicate are: 1) Get a bunch (okay, about 4-5 here) of windows open on a workspace (including Mozilla to make it easier, it seems) 2) Click in the Mozilla window so it's active (not necessary, but seems to make it easier) 3) Move to the tasklist on the panel and click on an icon for an unactive window (e.g. gnome-terminal or emacs) 4) Go back to step 3 several times, until you eventually notice that the window whose icon you clicked on isn't the one with focus (though you should see it focus momentarily before reverting to the previous window). Also, note that although the _NET_ACTIVE_WINDOW isn't focused, it is raised. I have a long log here from turning METACITY_VERBOSE on that seems to show what was going on if you're interested. I will attach a patch in a minute that fixes the problem, but there might be more work to be done somewhere. In particular, I'm really curious as to why we were getting _NET_CURRENT_DESKTOP messages for the currently active desktop.
Created attachment 30310 [details] [review] Activating the current workspace should be a no-op
libwnck probably always switches to a window's workspace. Your fix looks like the right one. Changing libwnck not to always switch is more questionable since it would be a race condition (libwnck may not know the current workspace accurately)
Okay, that makes more sense with what you say about libwnck not necessarily having accurate info. Perhaps I was also being confused by bug 128380? Did you want to look into this further? Did you want me to investiage anything? Or should I commit the patch?
I meant you should commit it, yep. It does sound like 128380 fix would fix this as a side effect, but I'd put this patch in as well, at minimum it's an optimization.
committed.
Let me note that this race condition was introduced by the fix in bug 120100 that I committed on August 2. So this race condition should only be observed in Metacity 2.8.2.
*** Bug 150683 has been marked as a duplicate of this bug. ***