Merge lp:~mterry/indicator-appmenu/less-racy-window-closing into lp:indicator-appmenu/0.3
Status: | Merged |
---|---|
Merged at revision: | 95 |
Proposed branch: | lp:~mterry/indicator-appmenu/less-racy-window-closing |
Merge into: | lp:indicator-appmenu/0.3 |
Diff against target: |
106 lines (+9/-39) 2 files modified
src/indicator-appmenu.c (+9/-5) src/window-menus.c (+0/-34) |
To merge this branch: | bzr merge lp:~mterry/indicator-appmenu/less-racy-window-closing |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Ted Gould (community) | Approve | ||
Review via email: mp+48381@code.launchpad.net |
Description of the change
I noticed an issue with shotwell menus over several opens and closes. It appeared that indicator-appmenu was not noticing when it closed, and when it opened again, giving it the old stale menus which was not desired.
Looking into it, it appeared to be a race condition between appmenu-gtk calling RegisterWindow and bamf knowing about the window from libwnck.
To make this less racy, I moved the window-close watching up a level, from the WindowMenus object itself to the IndicatorAppmenu object. Now all window-closes are watched, and the windows are removed from the hash table if they exist.
There's still a slight race here, that they could be opened and closed before RegisterWindow hits us, but that seems low-risk and certainly better than the current situation where every open is a race unto itself.
To be clear, the race before was that bamf_matcher_ get_application _for_xid might return NULL if bamf didn't know about the xid yet. Thus, the WindowMenus object wouldn't watch for its own destruction and would hang around forever.