Comment 6 for bug 388633

For many option menus, the items you are most likely to want to choose are those immediately before or after the currently selected one. This is true for more menus than those where you are most likely to want to change to the first item or the last item. Therefore, the most efficient behavior for an option menu is opening it so that the currently selected item is immediately under the pointer, because that results in least mouse movement and eye movement to access the previous/next items. Opening some menus this way, and some another way -- or worse, the same menu different ways depending on where the window happens to be on the screen -- would be nasty, because you could no longer rely on where the previous and next items were going to be, so you would be slower every time you used an option menu. (Indeed, we already have this problem with option menus in Firefox, Thunderbird, and OpenOffice.org, because they do not use the native GTK controls.)

This placement means that sometimes there are items that you need to scroll the menu to see, even though there is initially space available above or below the currently visible items. Currently GTK does this by drawing the menu to cover the area the items would take up if you scrolled far enough. In some cases this also provides a useful hint as to how long the menu is altogether (the Language menu in Epiphany's "Detailed Font Settings" is a good example of this). The drawback is that it looks a little odd.

It would be quite hard to measure whether abolishing the initial empty area slowed people down at all when using the menu, and if it did, whether the increase in beauty was worth it. But it isn't a clear enough case for us to diverge from upstream GTK.