GNOME Bugzilla – Bug 163343
window list sometimes not sending _NET_ACTIVE_WINDOW request on first click
Last modified: 2005-01-15 22:43:48 UTC
1 add the window list applet to a panel 2 open two different applications/windows 3 click on the application in the window list that is unfocussed The focus is lost of the first application/window but not given to the second one. We discussed this in #ubuntu and Sebastien Bacher couldn't reproduce is, but some others could. We also discovered that the time between entering the applet and clicking matters. If you do it fast enough, there's no problem. It happens all the time to me, unless I'm quick enough (within the second)
This issue also has been filed in Ubuntu bugzilla: https://bugzilla.ubuntu.com/show_bug.cgi?id=5350 I too have this issue.
Elijah: is this a known bug?
I just did a whole bunch of digging. Apparently, I can duplicate, though not with 100% reliability (perhaps I just don't know the complete steps yet?); it doesn't seem to be speed related to me. Steps I used: 1) Click on some window (i.e. not the tasklist, or the panel, or the desktop) 2) Click on the button for a different window than the activated window 3) If you don't see the bug, restart at step 1 Once you throw in step 3, of course, it is 100% reliable. :-) However, it seems to be that you don't need to repeat more than a handful of times and that it often can occur on the first try. The reason the previously focused window is being unfocused is due to metacity focusing the panel (see bug 160470--with the patch there, the previous window does not lose focus when this new bug is triggered). So the real problem is just with the new window not getting focus. I added a bunch of debugging stuff to Metacity and found that libwnck is not sending a _NET_ACTIVE_WINDOW message to Metcity in these cases. I don't know why, but I did discover that if you downgrade libwnck to a version prior to the following commit (despite the double entry, this is a single commit, it appears): 2004-12-15 Mark McLoughlin <mark@skynet.ie> * libwnck/tasklist.c: (make_gtk_label_bold): rename from eel_gtk_label_make_bold() and make static. 2004-12-15 Mark McLoughlin <mark@skynet.ie> Based on a patch from Juerg Billeter <j@bitron.ch> in bug #154040. * libwnck/tasklist.c: (wnck_tasklist_init), (wnck_tasklist_finalize): track tasklist instaces and call update_lists() on all instances when instances are added or removed. (wnck_tasklist_update_lists): only constrain the tasklist to showing windows from a certain monitor if its the only monitor. then the tasklist appears to function correctly. So it appears to be something from there. We'll have to look closer at those commits.
I've been staring at this for hours and I'm not making any progress. Anyway, my verbose debugging log that I built up showed that 1) wnck_task_button_press_event was being called as I expected 2) wnck_task_button_toggled (which apparently gets called a ridiculously large number of times), whenever the bug happened, (a) would be called less than normal and (b) would not call wnck_tasklist_activate_task_window This makes no sense to me. I also don't see why the patch I identified above (which I can get directly from the command 'cvs -q -z3 diff -pu -D "2004-12-15 3:10:00" -D "2004-12-15 3:20:00"') has anything to do with this, but my testing shows that somehow it does. *shrug*
Can you post that patch that seemed to introduce it?
Created attachment 35852 [details] [review] Patch that seems to cause the problem Other than the ChangeLog, this patch can be reverted cleanly. If I do so, the bug goes away.
Created attachment 35856 [details] [review] A smaller patch that's closer to pinpointing the bug Okay, in reposting the patch, I noticed something new and gave it a shot. My result is that here's a one line patch that makes the problem go away. However, I don't understand why it goes away and I also don't understand if it's okay to make this change (I don't understand what Juerg is trying to accomplish with this code).
Wild guess: monitor_geometry isn't initialized so in changed_geometry() monitor_changed is either inappropriately false or true and we update or don't update when we should not... valgrind might even be able to demonstrate this. But you could try just always putting something sane in monitor_geometry
Created attachment 35883 [details] [review] Test patch to fix wnck_tasklist_window_changed_geometry () I can't reproduce the bug on my non-multimonitor system but after looking at the code, I assume Havoc's guess is right. The one line patch is not valid as it would re-introduce bug #154040 AFAICT. Please try the attached untested patch, it may fix the problem.
Juerg: Yes, thanks for the patch. It does indeed fix the problem. While discussing this, though, note that the original patch applied in December also introduced some critical warnings (which apparently are part of the problem with the bug reported here)--see comments 2 and 3 of bug 149326 for more information and a patch that fixes those.
Ooops, sorry. Replace "which apparently are part of the problem" with "which apparently are NOT part of the problem". The patch in bug 149326 doesn't help with this problem at all, it merely solves a different problem that was introduced at the same time.
Comment on attachment 35883 [details] [review] Test patch to fix wnck_tasklist_window_changed_geometry () Looks good to me.
Committed to HEAD, thanks Juerg.