Git-bisected to http://git.gnome.org/browse/gnome-shell/commit/?id=69d6ae41415b478abf6598fc80d40f4ade7064c9

Definitely a bug, but not a really high priority one I think because it only happens if you're only running one app and you close it.

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 645698 ***

Ops... the original bug was lost in the outage, but I still had bug mail and didn't check...
Anyway I have a patch for this

Created attachment 184289 [details] [review]
AppMenu: fix visibility when going out of the Overview

Hiding the overview unconditionally called show(), irrespective of
current value of ShellWindowTracker:focus-app, meaning that sometimes
we were showing the app menu for closed applications or with windows
on a different workspace.

Review of attachment 184289 [details] [review]:

So we're losing the fade animation?  Intentional?  Or you just didn't care to preserve it?

::: js/ui/panel.js
@@ +274,3 @@
+            this._sync();
+        }));
+        // we use a custom flag instead of checking Main.overview.visible

How about to make this clearer, call it this._overviewWillBeVisible.

Review of attachment 184289 [details] [review]:

It bring regression on Bug 615099.

(In reply to comment #6)
> Review of attachment 184289 [details] [review]:
> 
> So we're losing the fade animation?  Intentional?  Or you just didn't care to
> preserve it?

.show() and .hide() both animate with fade.

> ::: js/ui/panel.js
> @@ +274,3 @@
> +            this._sync();
> +        }));
> +        // we use a custom flag instead of checking Main.overview.visible
> 
> How about to make this clearer, call it this._overviewWillBeVisible.

Ok

(In reply to comment #7)
> Review of attachment 184289 [details] [review]:
> 
> It bring regression on Bug 615099.

I can't reproduce it with this patch (tried closing a Firefox downloads dialog over main window, and a terminal window over another one).

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

Review of attachment 184289 [details] [review]:

> I can't reproduce it with this patch
Sorry, I misread patch.

From testing:

It _some_ time does not work and show warnings.

Window manager warning: CurrentTime used to choose focus window; focus window may not be correct.
Window manager warning: Got a request to focus 0x2800d65 (zaspire@wo) with a timestamp of 0.  This shouldn't happen!
Window manager warning: CurrentTime used to choose focus window; focus window may not be correct.
Window manager warning: Got a request to focus the no_focus_window with a timestamp of 0.  This shouldn't happen!

I think, another bug in mutter. I will look on it (later today).

::: js/ui/panel.js
@@ -250,3 @@
 
-        this.actor.reactive = false;
-        this._targetIsCurrent = false;

this._targetIsCurrent should stay.

@@ +272,3 @@
         Main.overview.connect('showing', Lang.bind(this, function () {
+            this._overviewVisible = true;
+            this._sync();

I think, logic about visibility should be in show/hide.
'show' should check _targetIsCurrent && _overviewWillBeVisible.

Retitling for clarity/searchability.

Created attachment 184485 [details] [review]
Fix problem with app menu showing when leaving overview

Giovanni's patch here seems to be along the lines of rewriting things
to work in a better way. We can debate whether the new way of doing
things is better or not better - and I tend to think that unifying
the two paths makes sense - but it's a little more intrusive than I'd
like at this point.

Here's a much simpler patch which at least appears on the surface to
be safer. I listed all the combinations of hiding and changing the
current at the same time, and it seems pretty good. The only
problems I found in that exercise are:

 - If you start entering the overview and the currentApp changes
   to null, then because onComplete isn't called, the app menu
   button is tweened to 0 opacity but not hidden. This should
   be OK ... there's not really any point to hiding it anyways.

 - If the current app changes to null, then you start entering
   the overview, the app blinks out instead of fading out.
   This isn't a huge deal and this case seems unlikely.

===

Since the opacity of the application menu is controlled by
it's _targetIsCurrent flag, we need to respect that when entering
and leaving the overview.

Comment on attachment 184485 [details] [review]
Fix problem with app menu showing when leaving overview

i believe this patch is correct other than the two bugs you mention, but i think we should leave the bug open and do something saner post-3.0.0

FWIW, users who have auto-login enabled and use wifi (so get the NM/keyring unlock dialog) will trigger this every login.

Comment on attachment 184485 [details] [review]
Fix problem with app menu showing when leaving overview

Pushed my simple patch as a pretty obviously safe improvement.
(release team sign-off: http://mail.gnome.org/archives/release-team/2011-March/msg00502.html)

Leaving open to clean things up and get a fix that doesn't have edge
cases that could leave things wrong.

(Start entering the overview, and before the overview finishes showing,
first switch from the focused app to no app and then from no app to another app, 
and the app menu would stick in the overview.)

Attachment 184485 [details] pushed as c5eb324 - Fix problem with app menu showing when leaving overview

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

645246 points out that even if you have no windows open at startup, then the app menu still starts out "visible" (with no icon and an empty label, but clickable padding).

See bug 650219 for a related issue where the fix got tripped up in the edge cases.

Is there anything left here?

I never experienced the original problem ever again since then!

I guess we can put this one to rest now.