GNOME Bugzilla – Bug 748919
window-list: can't switch app after a top bar menu is opened
Last modified: 2015-10-07 13:12:11 UTC
Steps to reproduce: * Activate the window-list extension * Open a few apps * Click on one of the top bar menu (date or top right menu) * When the menu is open, try to click on one of the window-list application icon to focus it The result is that clicking on a window-list app button has no effect. You first have to close the top bar menu and then the app button will work as expected. Tested on 3.14.4, 3.16.1 and 3.17.1.
To clarify: the first click on the window-list app button closes the top bar menu and isn't forwarded to the extension as expected. However, once the popup is closed it is the following clicks that have no effect.
Hi, i was going to create new bug and noticed yours. I have same problem. window-list does not respond to mouse clicks after moving mouse pointer from opened extension menu. Steps to reproduce: 1. open some window and minimize it 2. open some extension menu i.e. workspace switcher and leave it open 3. move mouse pointer over minimized window in window-list and click on it Results: 1. window will show only after multiple (sometimes 5 or more) mouse clicks 2. right-click dialog does not work Expected results: First mouse click should close opened menu and 2nd should un-minimize window. Tested and present in: 3.14.2, 3.18
Correction to Expected results: - Window should show after first mouse click. - Ditto for right mouse button dialog - Ditto for workspace switcher if we are moving from top bar menu
Could it be related to this bug? https://bugzilla.gnome.org/show_bug.cgi?id=724688
The expected result is that the first mouse click dismisses the menu, and the second mouse click activates the workspace switcher button. The fact that it doesn't indicates that the workspace switcher is missing an enter event that should be generated when the grab from the menu goes away.
I think you meant window button, Am I correct? Workspace switcher button (the bottom right button with "1/4" label) actually works okay. But window buttons are problematic. And thanks for correction, I didn't know that Gnome Shell menus have to be dismissed first before I can activate different menu/button.
Bug is present since initial version of extension
Created attachment 312772 [details] [review] test patch Can you look at this patch? Probably bad, but it seems to be working. Maybe it will give developers some idea how to fix this.
Created attachment 312773 [details] [review] st-button: Don't rely on hover to accept clicks Since commit 4f1f226828 we only consider buttons clicked when the release event had a corresponding press event. However as we use the hover state to check whether a release event actually occurred on the button, we dismiss any clicks in cases where we missed the enter event - most likely due to some other actor holding a grab. Instead, check whether the button contains the event's source, which should be less error-prone.
(In reply to rudolf from comment #8) > Can you look at this patch? Probably bad, but it seems to be working. Well, syncing up the hover state for any motion that occurs on the button or while the buttons has grabbed the button is a pretty big hammer. Unfortunately we don't have any way to detect when some unrelated actor dropped a grab and we should sync the hover state, and not even your broad approach works for all cases. However the patch I attached removes the requirement that buttons need to be hovered to be clicked, which reduces the wrong hover state to a visual glitch that's also present elsewhere (the dash for instance, or top bar items) - I don't think it is worth addressing this unless we have a proper hook to do it generically, in particular not by continually syncing hover states all over the place.
Review of attachment 312773 [details] [review]: makes sense
Attachment 312773 [details] pushed as 464d5d8 - st-button: Don't rely on hover to accept clicks