After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 645734 - With no apps active, last application Application name + icon shown in top panel when exiting activities overview mode
With no apps active, last application Application name + icon shown in top pa...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
2.91.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 645246 645833 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-03-26 11:19 UTC by Stéphane Démurget
Modified: 2012-10-31 12:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
AppMenu: fix visibility when going out of the Overview (3.61 KB, patch)
2011-03-26 14:22 UTC, Giovanni Campagna
needs-work Details | Review
Fix problem with app menu showing when leaving overview (1.24 KB, patch)
2011-03-28 17:27 UTC, Owen Taylor
committed Details | Review

Description Stéphane Démurget 2011-03-26 11:19:45 UTC
How to reproduce:
- start an app
- close it
- the app name + icon is correctly cleared
- go to overview mode (press windows key for example)
- leave overview mode
- notice how the name + icon of the last app (which is closed now) re-appear

I'm using Fedora 'updates-testing' channel to test all the gnome-shell releases and I only very recently hit this bug, and very often, so it's certainly a regression of 2.91.92.

That's too bad, because gnome3 is a very polished product and this glitch unfortunately makes it feel a lot less polished all of the sudden :-/

Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=691026
Comment 2 Colin Walters 2011-03-26 13:40:43 UTC
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.
Comment 3 Giovanni Campagna 2011-03-26 14:17:31 UTC
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 ***
Comment 4 Giovanni Campagna 2011-03-26 14:18:44 UTC
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
Comment 5 Giovanni Campagna 2011-03-26 14:22:15 UTC
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.
Comment 6 Colin Walters 2011-03-26 15:24:20 UTC
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.
Comment 7 Maxim Ermilov 2011-03-26 15:30:57 UTC
Review of attachment 184289 [details] [review]:

It bring regression on Bug 615099.
Comment 8 Giovanni Campagna 2011-03-26 16:36:53 UTC
(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).
Comment 9 Giovanni Campagna 2011-03-27 16:44:06 UTC
*** Bug 645833 has been marked as a duplicate of this bug. ***
Comment 10 Maxim Ermilov 2011-03-27 17:09:49 UTC
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.
Comment 11 Jean-François Fortin Tam 2011-03-27 18:16:50 UTC
Retitling for clarity/searchability.
Comment 12 Owen Taylor 2011-03-28 17:27:59 UTC
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 13 Dan Winship 2011-03-28 20:51:10 UTC
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
Comment 14 Gabriel Burt 2011-03-28 22:12:42 UTC
FWIW, users who have auto-login enabled and use wifi (so get the NM/keyring unlock dialog) will trigger this every login.
Comment 15 Owen Taylor 2011-03-29 03:12:07 UTC
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
Comment 16 Dan Winship 2011-04-11 20:28:17 UTC
*** Bug 645246 has been marked as a duplicate of this bug. ***
Comment 17 Dan Winship 2011-04-11 20:29:19 UTC
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).
Comment 18 Owen Taylor 2011-05-24 21:50:48 UTC
See bug 650219 for a related issue where the fix got tripped up in the edge cases.
Comment 19 Jasper St. Pierre (not reading bugmail) 2011-08-26 21:42:32 UTC
Is there anything left here?
Comment 20 Stéphane Démurget 2012-10-31 09:51:32 UTC
I never experienced the original problem ever again since then!
Comment 21 Jean-François Fortin Tam 2012-10-31 12:33:54 UTC
I guess we can put this one to rest now.