Items of a menubar built from GMenu do not always work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Application Menu Indicator |
Fix Released
|
High
|
Lars Karlitski | ||
indicator-appmenu (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Quantal |
Fix Released
|
High
|
Unassigned |
Bug Description
Impact:
sometime menu items are not working
Test Case:
wget https:/
"python test.py"
use the unity menu to do file->quit
run "python test.py" directly again
try to use file->quit
without the fix the menu item doesn't work after a quick restart, after the fix it does
Regression potential:
check that menu correctly represent the focussed applications and that items work as they should
---
In the attached example, the Quit menu item is supposed to work but sometimes it does not. If you start and quit the example repeatedly, you will eventually witness the Quit item having no effect when clicked.
This is happening with both Python 2 and Python 3, in both Quantal and Precise.
However, it seems to be happening only with the mouse: the keyboard accelerator (Ctrl+q) always works. Calling the action directly from dbus with
gdbus call --session --dest org.gnome.test --object-path /org/gnome/test --method org.gtk.
also seems to always work.
This issue seems exclusive to menus built with GMenu. Swallowed GtkMenuBars seem to always work fine.
ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: indicator-appmenu 12.10.3-0ubuntu1
ProcVersionSign
Uname: Linux 3.5.0-17-generic x86_64
NonfreeKernelMo
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Mon Nov 5 15:56:22 2012
InstallationDate: Installed on 2012-10-21 (15 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
SourcePackage: indicator-appmenu
UpgradeStatus: No upgrade log present (probably fresh install)
Related branches
- Ted Gould (community): Approve
- Charles Kerr (community): Approve
-
Diff: 121 lines (+1/-55)1 file modifiedsrc/indicator-appmenu.c (+1/-55)
Changed in indicator-appmenu: | |
status: | New → Triaged |
Changed in indicator-appmenu (Ubuntu): | |
status: | New → Confirmed |
Changed in indicator-appmenu: | |
importance: | Undecided → High |
assignee: | nobody → Lars Uebernickel (larsu) |
Changed in indicator-appmenu: | |
status: | Triaged → In Progress |
Changed in indicator-appmenu (Ubuntu): | |
importance: | Undecided → High |
Changed in indicator-appmenu: | |
status: | In Progress → Fix Committed |
no longer affects: | indicator-appmenu/12.10 |
Changed in indicator-appmenu (Ubuntu Quantal): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in indicator-appmenu (Ubuntu): | |
status: | Confirmed → In Progress |
Changed in indicator-appmenu: | |
status: | Fix Committed → Fix Released |
The cause of this is a five-second timeout in indicator-appmenu before it removes closed windows from its internal hash table. When an application restarts within these five seconds and X assigns the app's window the same xid, indicator-appmenu doesn't recognize it as a newly started application. It still shows the menus from the old instance (it has the menu model cashed), but action activations aren't send to the new instance.
The five-second timeout was added due to bamf bug #718926. This has been fixed since then, thus the timeout can be removed (see attached branch).