Got the same problem here, it disappeared (while trying to debug it) by going to the app search and back.

Also, I saw the message tray disappear in the overview, although it was working fine outside it.

I happens awfully often to me with gnome-shell 3.6.2.

I have found out that the workspace switcher will disappear if you type in the search box and quickly press Enter to launch the selected application before the shell is even able to display the application results. To reproduce simply open the Activies view, type 'A' and almost immediately hit Enter. Open Activies view again and notice the workspaces have gome.

The workspace switcher can be made show again by clicking the "Show Applications" button twice or by restarting the shell.

Created attachment 231494 [details] [review]
ViewSelector: fix showing the workspace page when opening the overview

Setting activePage at the beginning of the function meant that that
later _showPage() was shortcutted and did nothing, thus not restoring
the opacity of the workspacePage, causing occasionally to get stuck
hidden.

Review of attachment 231494 [details] [review]:

Nope - try '<super>a' outside the overview :-)

Well, just using the all-apps button "works" as well.

Created attachment 231497 [details] [review]
ViewSelector: fix showing the workspace page when opening the overview

Setting activePage at the beginning of the function meant that that
later _showPage() was shortcutted and did nothing, thus not restoring
the opacity of the workspacePage, causing occasionally to get stuck
hidden.
Also, fix the logic in showPage, which was backward and caused _activePage
to get stuck at null if never set from outside.

Review of attachment 231497 [details] [review]:

::: js/ui/viewSelector.js
@@ +204,3 @@
                                transition: 'easeOutQuad',
+                               onComplete: function() {
+                                   this.hide();

This works, but "this" is rather confusing here - maybe add a (redundant) onCompleteScope: this._activePage? Or use Lang.bind(this._activePage, ...)?

Created attachment 231498 [details] [review]
ViewSelector: fix showing the workspace page when opening the overview

Setting activePage at the beginning of the function meant that that
later _showPage() was shortcutted and did nothing, thus not restoring
the opacity of the workspacePage, causing occasionally to get stuck
hidden.
Also, fix the logic in showPage, which was backward and caused _activePage
to get stuck at null if never set from outside.

Review of attachment 231498 [details] [review]:

LGTM

Review of attachment 231498 [details] [review]:

Sorry, no - when first entering the overview by super-a, we still get it wrong.

Created attachment 231523 [details] [review]
ViewSelector: fix showing the workspace page when opening the overview

Setting activePage at the beginning of the function meant that that
later _showPage() was shortcutted and did nothing, thus not restoring
the opacity of the workspacePage, causing occasionally to get stuck
hidden.
Also, fix the logic in showPage, which was backward and caused _activePage
to get stuck at null if never set from outside.

This one should work...

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

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

The patch might be good for 3.6 (not tested), but it's obsolete in master, because the page handling and visibility code for overview controls was reworked significantly.
I'm not sure if this bug should be kept open.

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

(In reply to comment #14)
> The patch might be good for 3.6 (not tested), but it's obsolete in master,
> because the page handling and visibility code for overview controls was
> reworked significantly.
> I'm not sure if this bug should be kept open.

Apparently enough people are hitting it so it is worth to fix for 3.6.x ...

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

Hello, I see this once or more times a week, regularly for the last several+ months (it feels like years). rtcm pointed me to this bug and I reproduced it exactly using comment 2, even the workaround fix.

If there is a 3.6 patch release coming, this would be great to incorporate. Thanks.

Hey,

I'm running F18 with gnome-shell-3.6.3.1-1.fc18.x86_64

And I could also reproduce it as described in comment 2.

(In reply to comment #19)
> And I could also reproduce it as described in comment 2.

That's why the bug is still open :-)

This issue is on the list of fixes to include in another 3.6.x release, but at this point I'll need to set up a VM environment to do any testing, which isn't something I'll spend time on before 3.8.0 (or even 3.8.1).

(In reply to comment #20)
> (In reply to comment #19)
> > And I could also reproduce it as described in comment 2.
> 
> That's why the bug is still open :-)
> 
> This issue is on the list of fixes to include in another 3.6.x release, but at
> this point I'll need to set up a VM environment to do any testing, which isn't
> something I'll spend time on before 3.8.0 (or even 3.8.1).

:) Yes, my comment might just be a bit redundant. And I see that it doesn't apply for master. So I might just switch to 3.8 ... When it's available for F18... Thanks

(In reply to comment #21)
> So I might just switch to 3.8 ... When it's available for F18...

3.8 won't be available in F18. As mentioned before though, the plan is to include this in a 3.6.4 release (and submit it as an update to F18) some time after 3.8.0 is released.

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

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

3.6 is old and code has diverged a lot, so closing.