This seems to work properly for me now, not sure when/how it was fixed.
Reopen if it doesn't work for you.

It still doesn't work for me. I am using the gnome panel and libwnck
that came with Red Hat 9.

I kind of meant "if it still doesn't work for you in GNOME 2.4" ;-)

Has anyone else tested?

I have tested it again after upgrading to the panel and libwnck from
2.4, and the problem is still there, reproducible the same way:

1 focus some window
2 click in a different workspace
3 click in the first workspace, outside any window

This focuses the panel, not the original window.

Right, I can reproduce now too. I must have been clicking inside the
window instead of outside it on the first workspace.

presumably because the panel would be at the head of the MRU list at
that point.  Perhaps we should do the dock/desktop shuffle thing on
workspace switch as well?

This bug is driving my users nuts.  Is there a fix in site? 

We are using Fedora Core 1.

Thanks

Is this the same bug:

Goto a web page in Mozilla with a form.  Switch desktops (maybe to look up info
needed for the form).  Switch back to mozilla desktop.  Almost all of the time
mozilla will not give you focus for the form.  Mozilla itself might have focus,
but the form elements don't.

Interestingly enough, a switch to galeon appears to solve this problem, but
something is either wrong with mozilla or something focus related.

Tom: I'm pretty sure that can't be related.  If Metacity & libwnck were to
blame, then I would expect it to not work for either Galeon or Mozilla.

Focusing the window instead of the panel is correct for click-to-focus, but not
for sloppy-focus (at least not with current rules; though it would be when/if
the patch in bug 135810 gets applied), and not for mouse focus.  I'm guessing
that this extra info won't matter since I believe the fix would occur in (or in
conjunction with) meta_workspace_focus_mru_window, but I mention it just in case...

Created attachment 28969 [details] [review]
Don't focus panels

This patch removes windows of type META_WINDOW_DOCK and META_WINDOW_DESKTOP
from the list of windows that can be focused, having the effect that the window
won't be focused.  Note that the patch in bug 124981 will need to be applied as
well, otherwise both Metacity and libwnck will be attempting to focus windows
upon workspace switches.

Note that there's also a very closely related set of bugs -- bug 107681 and bug
128200.  This patch solves those bugs as well by having meta_window_minimize
also focus a window when the panel is the current window with focus.

Small correction.  The patch combined with the one in bug 124981 will fix the
bug for click-to-focus and mouse focus.  However
meta_workspace_focus_default_window focuses the window under the mouse for
sloppy focus, meaning that these two patches won't suffice for that focus
method.  To get sloppy focus working correctly as well, the patch in bug 135810
would also need to be applied.

Comment on attachment 28969 [details] [review]
Don't focus panels

if (workspace) { needs line 
break before the brace.

MetaWindow *focus_window = window->display->focus_window;
should declare and assign on different lines

I think this hack is sort of broken:
if (window->has_focus ||
+	   focus_window->type == META_WINDOW_DOCK)
You're saying "if a dock is focused and we happen to minimize something,
unfocus the dock" - what you really want I think is "if the dock is focused due
to clicking the window list applet unfocus the dock" - the right fix would
really be to not focus the dock in the first place... but if we have a hack
here, I think it's cleaner to have it in libwnck.

For the last hunk in focus_mru_window, this seems wrong to me; if the dock has
been focused, it should be in the mru list. We should just avoid focusing it
when we shouldn't? Unclear, that may not be possible. In any case, if there's
no other window to focus we should fall back to dock/desktop... so you can't
skip these unconditionally, just need to prefer everything else.

Created attachment 28993 [details] [review]
Corrected patch

I fixed the brace problem.  (Ooops, I should know better...)

The focus_window initialization isn't an issue anymore.

Yeah, that hack regarding minimizing windows from the panel doesn't seem so
clean.	However, I don't quite understand the idea of moving the hack to
libwnck.  libwnck doesn't know the focus mode, and thus it can't determine the
correct window to focus.  So Metacity really does need to do the
focusing/activating, and at least part of the patch belongs there (or am I
missing something?).  The cleanest thing I could think of was to have libwnck
send a signal to Metacity that it should focus a new window.  But having two
signals from libwnck to Metacity just to minimize a window seems dumb, yet
having just one signal means modifying the WM_STATE change signal.  (Maybe the
_NET_WM_STATE_MINIMIZED state, if accepted, could somehow handle this?)  I can
think of an alternate hack, namely to assume that any WM_STATE change signals
to iconify windows will imply that we need to focus a new window, ala:
--- src/window.c	24 Jun 2004 20:02:46 -0000	1.331
+++ src/window.c	24 Jun 2004 21:37:53 -0000
@@ -3966,7 +3966,10 @@ meta_window_client_message (MetaWindow *
		     event->xclient.data.l[0]);
       if (event->xclient.data.l[0] == IconicState &&
	   window->has_minimize_func)
-	 meta_window_minimize (window);
+	 {
+	   meta_window_minimize (window);
+	   meta_workspace_focus_default_window
(window->screen->active_workspace, NULL);
+	 }

       return TRUE;
     }
This has the advantage that the assumption is currently true, but even if the
assumption was somehow false then I believe that it the window that had already
been focused that would become focused again anyway.  However, it is another
hack, and it's strictly not relevant to this bug (I should probably move it to
bug 128200), so I don't have this or the old hack included in this patch.

Your comment about the focus_mru_window function doesn't make any sense to me. 
  The last little bit of the focus_mru_window function (which is executed if no
window is otherwise found by the routine) is:
      meta_topic (META_DEBUG_FOCUS, "No MRU window to focus found\n");
      meta_workspace_focus_top_window (workspace, not_this_one);
So, as you say, if no other window can be found then the dock or desktop will
be focused; it's just that all other windows take priority.

You're right about focus_mru_window I think.

I really don't like the "focus something else on minimize"; I think the only
reasonable thing to do may be to implement a way to keep the panel from getting
focused in the first place. I think there's a need for that for GOK as well.

The simple way is "don't focus docks on click" - but that will break things like
the dictionary applet, or at least require them to explicitly request focus, so
we'd need to coordinate with wm-spec-list on this point.

There are more elaborate solutions and some of the GOK and raise-on-click
threads may discuss them.

Does it make sense to put in the rest of the patch while we try and sort this out?

Yes, it definitely makes sense to put the rest of the patch in (it'd fix the
focus-the-right-window-after-clicking-in-the-pager-problem).  We can then move
the rest of the discussion about what to do on minimization to bug 128200 (+ the
wm-spec-list and whatever else is required (: ).

Havoc: Did you mean your question as approval to commit the latest patch (the
one that doesn't include the "focus something else on minimize" behavior)?  I
was waiting for you to manually change the attachment state, but just realized
that maybe you meant your comment to be approval enough.

Yeah, I meant commit all the uncontroversial bits

I committed the uncontroversial part.  Since the controversial part was an
attempt to also fix a different bug (bug 128200/bug 107681), I'll go ahead and
mark this one as fixed.

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

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