GNOME Bugzilla – Bug 778444
Pop-up menu overlaps with pointer and triggers unintentional hold-and-click
Last modified: 2018-04-15 00:05:20 UTC
This bug has originally been posted against Evolution, where it has been observed (bug #778220), but was closed as duplicate of bug #591258. However, bug #591258 has been solved and closed. I am filing it here because I still think it is a different bug, maybe Evolution-specific, but cannot know for sure. Bug description: when the attachment drop-down menu is selected (left-click), if the button is too close to the bottom of the screen and if the attached file can be displayed in the message body, the first available item is selected in a hold-click behavior because the menu overlaps the button and hence the pointer. If the attached file is in a format which cannot be displayed in the message body, then the hold-click behavior is not triggered. Hold-click is fine, click-twice is fine, but the inconsistent behavior is buggy. The full discussion of the bug in bug #591258 starts here: https://bugzilla.gnome.org/show_bug.cgi?id=591258#c63.
Created attachment 345432 [details] Drop-down menu button to select action for Evolution attachment
The problem seems to be caused by a shorter delay before the activation of the hold-click behavior when the attachment can be displayed in the message body. The delay appears to be longer when the attachment cannot be displayed in the message body, hence the unpredictable outcome.
This bug seems to be still present in the latest stable release, annoying as it may be for Evolution power users. In Evolution, the attachment drop-down menu is the only one to be affected because it is the only one to overlap with its own trigger button: the menu bar drop-down menus are displayed either above or below their respective trigger button and the right-click contextual menu is always displayed with a margin to the position of the pointer at the time of the click. A similar behavior for the attachment drop-down menu would avoid the accidental activation of an unwanted action while retaining the benefits of the hold-and-click behavior. NB: the attachment drop-down menu is displayed below its trigger button when enough space is available, so there is no overlap. Could it be made to appear above that trigger button when there is not enough space available above, instead of overlapping with it?
The following property seems to have the potential to fix that annoying behavior, at least for those of us who first reported in Evolution: https://developer.gnome.org/gtk3/unstable/GtkMenu.html#GtkMenu--anchor-hints It seems very likely that the GDK_ANCHOR_FLIP_Y hint applied to the attachment pop-up menu would perfectly do the trick, though it is not clear to me whether it would override the existing behavior which instead stacks the menu items on the bottom of the screen (and thus creates the overlap between the popup menu and the trigger button). Anyway, this property is still marked unstable in 3.22. Is there any stable GtkMenu property to the same effect? As already mentioned, other drop-down buttons in Evolution - and as a matter of fact, elsewhere in gtk+ environments - display their trigger menu overhead instead of stacking on the bottom of the screen. Is that supposed to be the default behavior?
(In reply to Robert Andrew from comment #4) > Anyway, this property is still marked unstable in 3.22. Is there any stable > GtkMenu property to the same effect? As already mentioned, other drop-down > buttons in Evolution - and as a matter of fact, elsewhere in gtk+ > environments - display their trigger menu overhead instead of stacking on > the bottom of the screen. Is that supposed to be the default behavior? That "unstable" annotation should almost certainly be removed; GTK+ 3.22 is now an LTS release, so API will not be removed (unless it was completely broken, which this isn't) - and especially not API that e.g. other widgets like GtkComboBox use. GtkMenu is the only widget that has any symbols marked as Unstable. My guess is they're fine to use and the annotations should be removed. I can open a new bug to check on that. In the meantime, would you be able to experiment with this on Evolution, by giving these hints a go? That way we can determine whether there's any need to consider any changes on this side (which would not come for free and may hinder other uses).
Re the Unstable annotations, see https://bugzilla.gnome.org/show_bug.cgi?id=785875
Thank you for your feedback Daniel. I have updated the evolution bug to suggest using these anchor hints. I will report back here if I get any reply. I am still struggling to understand why the hold-and-click delay is different when the attachment can be displayed in the message body, all other things equal. This seems to be the main source of the problem. Anyway, I do realize that the position of that button on the Evolution GUI is not very common, so the problem might have limited scope in terms of users affected (vs. potential disruption if the underlying GTK+ behavior is modified).
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new