GNOME Bugzilla – Bug 675942
Weird behavior when a menu is higher than the screen
Last modified: 2017-10-09 11:32:47 UTC
Created attachment 213920 [details] Evolution's "Message" menu showing the bug Evolution's "Message" menu has many items, and it doesn't fit on my 1366x768 px laptop screen. In 3.4, instead of getting scrollbars, the menu seems to move up, and completely hides the menu title. This is very weird, because the menu item at the top of the menu gets unexpectedly under the pointer, and becomes selected. This means that simply clicking on the menu title to open the menu results in activating the first item in it. You need to click and hold to select another item (which is what I'm doing in the attached screenshot). This is with GTK+ 3.4.1 and Evolution 3.4.1 on Fedora 17.
*** Bug 676883 has been marked as a duplicate of this bug. ***
Duplication if information from https://bugzilla.gnome.org/show_bug.cgi?id=676883 TLDR: This sppears to affect most applications using "modern" GTK+ menus, not just evolution. ### gnome-shell version 3.2.2.1-4+b1, Debian testing Menus in several GNOME applications behaves inconsistently when they are larger than the screen height: 1. Menu selects items on release rather than remaining open 2. Menu overlaps the menu entries, including itself - See attachements too-large-menu.png and normal-menu.png respectively On my current resolution (1366x768) I am only experiencing this with the Evolution "message" menu, however if I change my resolution down to 640x480, I see the same issue in the Gedit "file" menu, the Nautilus "edit" and "view" menus, the Transmission "view" menu, etc. so it appears to be consistent over many (all core?) GNOME applications. Issue 1 appears to be due to the click-release "landing" on a menu item, rather than the menu button itself, which in turn is caused by the point 2 behaviour. (Note that if the item "landed on" is inactive the issue is not seen, since clicking it does nothing anyways.) I'm not sure if the overlapping behaviour in point 2 is intentional (it may be a good thing to use as much of the screen for the menu as possible, or not..). The alternative would be to do something similar to what GIMP does, see "gimp-menu.png" attachment, this would probably fix both issues in one go. Otherwise, if the overlapping should remain, I would like to see the same behaviour when clicking and releasing on a menu which is too large as would clicking a normal menu.
Created attachment 215068 [details] Too large menu
Created attachment 215069 [details] Normal menu
Created attachment 215070 [details] GIMP menu
*** Bug 685384 has been marked as a duplicate of this bug. ***
*** Bug 745016 has been marked as a duplicate of this bug. ***
This issue is not limited on menus which are higher than the screen. On testing this it seems if a menu is spawning directly under the position of the mouse cursor releasing the mouse button does not activate an entry with a few exceptions (holding the mouse button longer before releasing it or moving the mouse a bit and releasing it seem to activate the menu entry on a mouse release). SciTE has this issue on the GTKFileChooser with the file type dropdown menu too while it is normally not higher than the screen. On clicking the dropdown field which defaults to "All Source" and immediately releasing the mouse button the entry "All Source" from the menu is selected and it immediately closes. But this happens only the first time on a GTKFileChooser instance as clicking the dropdown field again causes it not to select "All Source" again while the position of the pointing device is still over it. I'm also noticing that the first time this dropdown menu is opened it seems to get generated and positioned while this is not the case on opening it again. So actually it looks like these menus should normally not close on an immediate mouse button release even if a clickable entry is below the mouse cursor but a bug is causing it. Maybe the generation/positioning of these menus count as a mouse movement or such and I wonder if this bug can simply be fixed if menus are generated/positioned before they are being shown.
*** This bug has been marked as a duplicate of bug 591258 ***