works for me.

Works for me too.  I believe someone else reported this not too long ago (don't
remember the exact bug number), but they explicitly said to have normal windows
on each desktop (well, and maybe they were maximized too?).  I wonder if this is
distro specific in some way?

Could you give us some distribution/version information, fork0?

SuSE 9.1. That's a machine at work, and though I was sure at that moment it was
2.8.0, I'll recheck tomorrow (SuSE 9.1 still has 2.6.3 according to archives).
I have the problem at home as well (Gentoo, 2.6.5), but isn't always reproducable.
Not at this very moment, for instance ~:/

I have already filed a similar report, btw. But it took some time to find it,
and I lost patience and filed it anew today. The old bug was 114118, filed
against 2.4.

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

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

Bug 145028 was the other bug I was thinking of.  fork0: What configuration
options do you have set for Metacity?  How reproducable is this for you?  (i.e.
is it like bug 94422 where you do the exact same thing every time and the bug
occurs 5% of the time, or is it something you observe more like 70% of the time?)

For Gentoo (my machine at home): only defaults
For SuSE 9.1 (at work, taken from specfile):
 CFLAGS="$RPM_OPT_FLAGS -fno-strict-aliasing" \
  ./configure --prefix=%prefix --sysconfdir=%sysconfdir \
    --datadir=%prefix/share --localstatedir=/var/%_lib \
    --libexecdir=%{prefix}/%_lib/metacity --libdir=%prefix/%_lib \
    --disable-schemas-install

The RPM a took this from is at:                     
ftp://ftp.belnet.be/linux/suse/suse/i386/9.1/suse/src/metacity-2.6.3-67.src.rpm

Thanks, but I was thinking more along the lines of do you have autoraise turned
on, did you set the reduced resources gconf flag to true, etc...

at home: application_based=false, auto_raise=false, disable_workarounds=false,
reduced_resources=false (it's 2.8.1 already, so there probably is no point)

at the office: can't really say, sorry.
The said machine is not available to me now. Will update tomorrow

The version in question is 2.8.0. There is no any special options set (and
listed) in metacity configuration, the only I can think of, disable_workarounds,
is set to false.
I'll retest with 2.8.1 now.

seem to be fixed in 2.8.1.

The reporter does not see the bug anymore, closing. 

Aha!  I can duplicate.

1) Set gconf key /apps/metacity/general/focus_mode to mouse (this does NOT
   happen in CVS HEAD with either sloppy or click focus methods, though, 
   considering bug 135810 and what I think is happening, it would have
   occurred for sloppy focus for older releases)

2) Make sure you have a workspace where there is a window underneath where the
   workspace switcher popup window will appear.  (Personally, three of my four
   workspaces were like that when I discovered how to do this)

3) Make sure you have a neighboring workspace where there is NO windows
   underneath where the workspace switcher popup window will appear.

4) Move to the workspace where there is a window beneath that location.

5) Move the mouse to somewhere inside that location where the workspace
   switcher pop window will appear.

6) Use the appropriate ctrl-alt-arrow keybinding to switch to the workspace
   where the mouse won't be in a window (make sure not to move the mouse
   before doing this).

No wonder we couldn't duplicate...that's sort of rare.  :-)

Created attachment 30281 [details] [review]
Focus the no_focus_window if no other window is found to focus

Here's the patch that fixes the problem for Metacity 2.8.2 and CVS HEAD.  (Due
to the change in bug 135810, it won't cleanly apply to older versions, but
shouldn't be hard to backport; just cut and paste the same stuff to the
appropriate function(s))

ah yes; that would do it.  Good catch.  I don't know how you managed to
reproduce this bug, but I'm glad you did :-)

Does that imply "accepted; commit now"?  ;-)

Probably should use meta_display_get_current_time instead of CurrentTime there.
 I know it's just going to return CurrentTime, but perhaps, one day, in a better
world, it won't.  I also wonder if we shouldn't have a
meta_display_focus_no_focus_window function, since we have that same big ugly
call to XSetInputFocus in like 4 places now.

http://tronche.com/gui/x/xlib/input/XSetInputFocus.html claims that if you pass
CurrentTime then the xserver will replace it with the current X server time;
isn't that what we want?

But if we ever call meta_workspace_focus_default_window from inside an event
handler we want it to use the timestamp of the event.  This avoids potential
focus race conditions.  Passing CurrentTime to the X server incidentally always
will replace CurrentTime with the current server time.

Created attachment 30283 [details] [review]
use meta_display_get_current_time

Ah, that makes sense.

Do you also want me to try to put together a meta_display_focus_no_focus_window
function?  (That does make sense, since I more or less copied from the
LeaveNotify event in display.c in order to figure out how to make this patch. 
:-)

um, sorry to be a curmudgeon, but is there a reason you changed from meta_topic
to meta_verbose?

Uh, because I was cutting-and-pasting from display.c (event_callback() under the
LeaveNotify case)?  I'll fix the patch and re-post in a minute...

Created attachment 30284 [details] [review]
s/meta_verbose/meta_topic/.  :-)

Comment on attachment 30284 [details] [review]
s/meta_verbose/meta_topic/.  :-)

Does that compile?

s/meta_topic (/meta_topic (META_DEBUG_FOCUS/

go ahead and commit with that change :-)

Created attachment 30285 [details] [review]
I'm a complete moron.

WHHOOOOOOPPPSS.  :-}  Here's the patch that compiles.  I'll commit in just a
minute.

commited.

Reopening, bug isn't completely fixed with this patch..

Better test case scenario :

1/start X with only a terminal inside (startx /usr/X11R6/bin/rxvt for instance)
2/in that terminal, run metacity 
3/make sure mouse focus is the current mode
4/position mouse cursor on the location of the worspace switcher
5/press Ctrl-Alt-Right to switch to a completely empty workspace

=> workspace switcher won't disappear when releasing keys combinaison.

Patch seems to work only if at least one window can be focus in the workspace
(which is often the case if you have a panel but not always).

First, do you really mean 'mouse' focus, or do you mean sloppy focus?  (Sorry to
ask, but many people mix them up).  I can think of a case where this would
happen for both sloppy focus and click-to-focus, and the following patch should
fix that:

Index: src/workspace.c
===================================================================
RCS file: /cvs/gnome/metacity/src/workspace.c,v
retrieving revision 1.60
diff -p -u -r1.60 workspace.c
--- src/workspace.c     27 Aug 2004 17:22:54 -0000      1.60
+++ src/workspace.c     10 Sep 2004 18:00:13 -0000
@@ -899,6 +899,12 @@ meta_workspace_focus_top_window (MetaWor
     }
   else
     {
-      meta_topic (META_DEBUG_FOCUS, "No top window to focus found\n");
+      meta_topic (META_DEBUG_FOCUS,
+                  "Setting focus to no_focus_window, since absolutely no "
+                  "windows exist.\n");
+      XSetInputFocus (workspace->screen->display->xdisplay,
+                      workspace->screen->display->no_focus_window,
+                      RevertToPointerRoot,
+                      meta_display_get_current_time (workspace->screen->display));
     }
 }

But this shouldn't affect mouse focus.

Second, you might just be a experiencing bug 151554 (which I believe is the same
as bug 142947 and bug 152169); we'd need to know the output of xmodmap and which
ctrl and alt keys you are using to find out.

Argggggggg, I thought just enabling "focus follow mouse" in metacity capplet was
enabling mouse focus, not sloppy focus (now, you can say : Mdk metacity packager
didn't knew difference between sloppy and mouse focus :)). My test case was in
fact in sloppy focus mode, while I thought I was testing mouse focus mode.

I've got reports from other people on Mdk bug
http://qa.mandrakesoft.com/show_bug.cgi?id=11359.

I'll try this patch on Monday and I'll let you know but it is probably fixing
the issue..

Confirmed, it is fixed with this patch.

Leaving bug opened until patch is committed..

Created attachment 31540 [details] [review]
Alternate patch to fix the remaining issue pointed out by Frederic

Here's a patch that depends on the one in bug 151990 being applied first.  In
addition to fixing the bug Frederic pointed out, this patch makes the panel and
desktop windows only be focused when the user explicitly requests it (which we
claimed we were doing before, but it was a lie).  Doing this extra thing allows
a little bit of code clean-up to be taken care of at the same time.

Comment on attachment 31540 [details] [review]
Alternate patch to fix the remaining issue pointed out by Frederic

Seems logical to me, thanks.

Comment on attachment 30285 [details] [review]
I'm a complete moron.

Should this really be flagged committed?

Yes, attachment 30285 [details] [review] was committed over a month ago; I never marked it as
committed at that time because I just marked the bug as fixed instead.  After
Frederic reopened this bug and I posted a new patch, I didn't want you getting
confused about which patch to look at, so I marked the old patch that had been
applied to CVS as committed.  

(As to the differences between the patches: Note that while the 30285 patch
looks very similar, it was actually code for the focus_default_window function,
while the newer patches are for the focus_mru_window and focus_top_window functions)

committed.

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