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 724688 - window-list: Fix some menu issues
window-list: Fix some menu issues
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: extensions
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-02-18 20:12 UTC by Florian Müllner
Modified: 2014-02-18 21:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window-list: Sync hover after closing menus (3.34 KB, patch)
2014-02-18 20:12 UTC, Florian Müllner
committed Details | Review
window-list: Only have a single context menu at any time (2.17 KB, patch)
2014-02-18 20:12 UTC, Florian Müllner
committed Details | Review
window-list: Call destroy() on menus instead of their actors (1.88 KB, patch)
2014-02-18 20:12 UTC, Florian Müllner
committed Details | Review

Description Florian Müllner 2014-02-18 20:12:13 UTC
To reproduce the first issue:
1. open a window-list menu (doesn't matter if it's context menu or window list)
2. dismiss by clicking a different window-list button
3. click again to trigger the other button's menu

3. will fail until leaving and re-entering the button.


The second issue happens for app buttons with a single window; the most common symptom is sluggish right-click menu opening/closing, but I have observed other deficits like the menu not opening at all and confused grabs occasionally.
Comment 1 Florian Müllner 2014-02-18 20:12:17 UTC
Created attachment 269611 [details] [review]
window-list: Sync hover after closing menus

StButton takes the hover state into account to decide whether a
series of events should be considered a click. So when dismissing
a menu by clicking on a different window/app button, its menu
cannot be triggered before leaving and re-entering the button
(and thus syncing the hover state).
Fix this by always syncing the hover state after a grab is dropped.
Comment 2 Florian Müllner 2014-02-18 20:12:22 UTC
Created attachment 269612 [details] [review]
window-list: Only have a single context menu at any time

Depending on the number of windows, AppButtons use different right-click
menus ("Minimize" vs. "Minimize all").
As the menu for the multiple-windows case remains the same, it is created
and added just once. However this means that in the single-window case,
the corresponding PopupMenuManager will track two menus for the same
source actor, resulting in various misbehaviors.
Fix these issues by adding and removing the app context menu appropriately,
so that the PopupMenuManager tracks a single menu at any time.
Comment 3 Florian Müllner 2014-02-18 20:12:27 UTC
Created attachment 269613 [details] [review]
window-list: Call destroy() on menus instead of their actors

PopupBaseMenu provides a destroy() method that will destroy the menu
actor and make sure that the menu will be removed from the corresponding
PopupMenuManager (if any). We miss the latter when we destroy the menu
actor directly, so use the menu method instead.
Comment 4 Giovanni Campagna 2014-02-18 21:20:01 UTC
Review of attachment 269611 [details] [review]:

Ok
Comment 5 Giovanni Campagna 2014-02-18 21:21:23 UTC
Review of attachment 269612 [details] [review]:

Ok
Comment 6 Giovanni Campagna 2014-02-18 21:21:48 UTC
Review of attachment 269613 [details] [review]:

Definitely.
Comment 7 Florian Müllner 2014-02-18 21:46:33 UTC
Attachment 269611 [details] pushed as c2fe2b5 - window-list: Sync hover after closing menus
Attachment 269612 [details] pushed as b87ddf1 - window-list: Only have a single context menu at any time
Attachment 269613 [details] pushed as 3cde65e - window-list: Call destroy() on menus instead of their actors