GNOME Bugzilla – Bug 703069
Opening a big menu activates some menu entry
Last modified: 2017-10-08 16:38:48 UTC
(Couldn't find a bug for this, but there are so many menu bugs that I may have missed one...) Say an application menu is a bit too big, or your screen resolution is a bit too small, or you have a non-maximized application placed such that the menu bar is in the middle of the screen, or your gtk+ theme makes menu be a bit bigger than usual, or any combination of those. Now what happens if you click on that menu (e.g. "View") is that the menu popup doesn't fit entirely below "View", and it doesn't fit entirely above it either. What gtk+ does then is open it on top (which is fine). See the attached screenshot. Let's see what happens when you click on the menu a) button-press-event, gtk+ opens the menu. the mouse is now on top of one of the menu entries. b) button-release-event, received by the menu entry. If the menu entry is a submenu, that gets opened, but if it's a normal entry, that gets activated and the menu is closed. The effect is that the menu opens and closes really fast and depending on what was clicked, you may not know what's happened or you may have accidentally done something undesirable.
Created attachment 247757 [details] screenshot
I think a good solution for this would be: if (button-press originated in the menu shell) and (not long-press) ignore or more generically: if (button-press originated in the parent) and (not long-press) ignore i.e. if we activate a menu (say "Edit") in the menu shell with button-press and then button-release activates a submenu entry (say "Copy"), we only activate it if it was a long press. If it's a short press but it was originated in the item itself (or perhaps in any item in the submenu, but not in the parent) we activate it.
Created attachment 247928 [details] [review] menushell: don't activate a menu entry when opening a big menu If a menu is opened and it doesn't fit entirely below or above the menu bar, gtk+ will place it on top. The button release will then activate the popup item that happens to appear under the cursor. Avoid this by ignoring release events if they originated in the parent menu bar and the duration of the press was too short.
I tried to implement the logic from comment #2 in the above patch. I will not claim to have covered every possible scenario or to have fully understood the gtkmenu* logic, but I have played with the menus and the above patch a bit and from my tests this solves the issue at hand and doesn't bring any regressions.
Reviewed by Benjamin on irc. Pushed to master and gtk-3-8.