GNOME Bugzilla – Bug 781992
GtkMenuButton with no popover retains prelight state when no longer selected
Last modified: 2017-05-08 14:11:01 UTC
If a GtkMenuButton uses a GMenu but *does not* use a popover, then it will retain its prelight state even after the menu has been deactivated. This causes an obvious graphical glitch for any menu that's constructed in this manner. Look at gnome-terminal's tab selection menu (only visible when there are multiple terminal tabs) for an example of this issue: click on the menu button, then either select one of the menu items or click anywhere else in the app and the menu button will improperly retain its prelight state. The attached GTK+ 3 patch fixes this. It's probably a hack rather than the correct fix, but it shows the desired behavior at least. I want to change Epiphany to use a traditional menu instead of a popover menu in order to make its tab selection menu scrollable; however, that's blocked on this problem.
Created attachment 350773 [details] [review] menubutton: Remove prelight state when button is deactivated If the button is deactivated, it should not appear to be hovered anymore.
I guess the more general problem is that a popup window means the parent window can't really have any hovered window anymore, but nobody notices that normally since widgets have to implement :hover handling themselves and buttons usually don't have right-click context menus... Since hovering is done in every widget that supports it, I'm fine with the approach in the patch and don't even consider it a hack. I briefly thought it would break the case where the pointer stays inside the button and the menu is dismissed using ESC, but that's not the case.
Note: this is to fix normal left-click menu buttons. I don't know why it affects some menu buttons and not others.
Review of attachment 350773 [details] [review]: OK
Pushed to both master and gtk-3-22