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 643867 - Unexpected app menu when all apps closed
Unexpected app menu when all apps closed
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
Depends on:
Blocks:
 
 
Reported: 2011-03-04 13:21 UTC by Yu Chen
Modified: 2012-01-27 18:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot for proof (149.96 KB, image/png)
2011-03-04 13:21 UTC, Yu Chen
  Details
popup-menu: Do not open empty menus (1.60 KB, patch)
2011-11-15 14:01 UTC, Florian Müllner
committed Details | Review
AppMenuButton: only show the button if the target app is on the current ws (1003 bytes, patch)
2011-11-16 00:33 UTC, Rui Matos
committed Details | Review
AppMenuButton: remove can_focus property when hiding (1.11 KB, patch)
2011-11-16 00:33 UTC, Rui Matos
reviewed Details | Review
AppMenuButton: bind "can-focus" to "reactive" (915 bytes, patch)
2012-01-27 18:05 UTC, Rui Matos
committed Details | Review

Description Yu Chen 2011-03-04 13:21:26 UTC
Created attachment 182460 [details]
screenshot for proof

When all the apps are closed, if we click date/time on the top panel, and then press left arrow key, there will be an unexpected app menu of the last quited application appears as shown in attached screenshot.

gnome-shell is from fedora 15
Comment 1 André Klapper 2011-05-06 10:13:18 UTC
Is this still an issue in 3.0?
Comment 2 Yu Chen 2011-05-06 10:37:40 UTC
(In reply to comment #1)
Yes, same as before in updated Fedora 16 today.

Even worse:
1) open a gnome-terminal one the first workspace 
2) switch to second workspace, open a gedit application;
3) quit the gedit,
4) now the second workspace is empty and gnome-shell auto enter the overview mod
5) left click the second workspace in workspaces thumbnail bar, switch back to normal view mod
6) take a look at the position of app menu in top bar, you will see the gnome-terminal icon and the name of the app appears.
Comment 3 Yu Chen 2011-05-06 10:49:49 UTC
(In reply to comment #2)

If it can not be reproduced immediately, you can take an additional action: just move the gedit window a bit with your mouse before close it.
Comment 4 Matthias Clasen 2011-11-15 12:59:18 UTC
Still seeing this with 3.3
Comment 5 Florian Müllner 2011-11-15 14:01:22 UTC
Created attachment 201440 [details] [review]
popup-menu: Do not open empty menus

There is little point in showing an empty menu, so return early from
open() if the menu does not contain any items.
Comment 6 Rui Matos 2011-11-16 00:32:08 UTC
Review of attachment 201440 [details] [review]:

This patch is correct but it doesn't fix this bug. I think it can go in anyway.
Comment 7 Rui Matos 2011-11-16 00:32:58 UTC
There are actually 2 bugs described here. The following patches fix each one of them independently.
Comment 8 Rui Matos 2011-11-16 00:33:34 UTC
Created attachment 201499 [details] [review]
AppMenuButton: only show the button if the target app is on the current ws

When the last window on a workspace is closed the focus goes to some other
window in another workspace which would cause us to show the AppMenuButton for
an application that isn't visible on the current empty workspace.
Comment 9 Rui Matos 2011-11-16 00:33:47 UTC
Created attachment 201500 [details] [review]
AppMenuButton: remove can_focus property when hiding

When changing to an empty workspace we make the AppMenuButton invisible but
the user could still get to the menu using keyboard navigation.
Comment 10 Florian Müllner 2012-01-27 12:33:36 UTC
Comment on attachment 201440 [details] [review]
popup-menu: Do not open empty menus

Attachment 201440 [details] pushed as 5530891 - popup-menu: Do not open empty menus
Comment 11 Florian Müllner 2012-01-27 12:48:08 UTC
Review of attachment 201499 [details] [review]:

Makes sense.
Comment 12 Florian Müllner 2012-01-27 14:40:56 UTC
Review of attachment 201500 [details] [review]:

Hmm, is that really necessary? I can't reproduce the problem without the patch (maybe because get_focus_chain() only takes visible children into account?). Still, shouldn't do any harm applying the patch anyway (we could get fancy though and use something like this.actor.bind_property("visible", this.actor, "can-focus", 0))
Comment 13 Rui Matos 2012-01-27 16:38:00 UTC
Comment on attachment 201499 [details] [review]
AppMenuButton: only show the button if the target app is on the current ws

Attachment 201499 [details] pushed as 21e2280 - AppMenuButton: only show the button if the target app is on the current ws
Comment 14 Rui Matos 2012-01-27 17:28:29 UTC
(In reply to comment #12)
> Review of attachment 201500 [details] [review]:
> 
> Hmm, is that really necessary? I can't reproduce the problem without the patch

It's quite easy for me:
0. Must be out the overview
1. Change into the last (always empty) workspace with Ctrl+Alt+Down
2. Click the clock, the calendar menu appears
3. Press the left arrow key, the app menu shows up

> (maybe because get_focus_chain() only takes visible children into account?).

The code only toggles visibility when going in and out of the overview. When changing into an empty workspace the opacity is simply tweened to 0. I remember trying to call this.show/hide on that tween completion but things would get confused when going in and out the overview then. This might be the better solution but further changes would be needed I think.

> Still, shouldn't do any harm applying the patch anyway (we could get fancy
> though and use something like this.actor.bind_property("visible", this.actor,
> "can-focus", 0))

This function isn't available to JS code.
Comment 15 Florian Müllner 2012-01-27 17:44:51 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > Review of attachment 201500 [details] [review] [details]:
> > 
> > Hmm, is that really necessary? I can't reproduce the problem without the patch
> 
> It's quite easy for me:
> 0. Must be out the overview
> 1. Change into the last (always empty) workspace with Ctrl+Alt+Down
> 2. Click the clock, the calendar menu appears
> 3. Press the left arrow key, the app menu shows up

Ah, OK then - I only checked with Ctrl-Alt-Tab, which somehow worked fine.


> > Still, shouldn't do any harm applying the patch anyway (we could get fancy
> > though and use something like this.actor.bind_property("visible", this.actor,
> > "can-focus", 0))
> 
> This function isn't available to JS code.

That's wrong (though "visible" doesn't work according to your explanation, using "reactive" however works just fine). Anyway, it's only a suggestion - I don't have a problem with setting it explicitly as in the current patch.
Comment 16 Rui Matos 2012-01-27 18:05:31 UTC
Created attachment 206295 [details] [review]
AppMenuButton: bind "can-focus" to "reactive"

--
Now with 50% less lines! ;-)

(In reply to comment #15)
> > > Still, shouldn't do any harm applying the patch anyway (we could get fancy
> > > though and use something like this.actor.bind_property("visible", this.actor,
> > > "can-focus", 0))
> >
> > This function isn't available to JS code.
>
> That's wrong (though "visible" doesn't work according to your explanation,
> using "reactive" however works just fine). Anyway, it's only a suggestion - I
> don't have a problem with setting it explicitly as in the current patch.

Ok, it works now that I updated gobject-introspection.
Comment 17 Rui Matos 2012-01-27 18:08:55 UTC
Attachment 206295 [details] pushed as bdd65fe - AppMenuButton: bind "can-focus" to "reactive"