GNOME Bugzilla – Bug 591258
Easy to accidentally select first option in popup menus
Last modified: 2018-07-06 07:17:15 UTC
At the moment it's to easy to accidentally select the first option in a popup menu when right-clicking with some themes [1]. This is a big problem in eg nautilus were a right-click often creates an extra folder, but problem also exists in other applications. The right place to fix this seems to be gtk. My suggestion is to 1) move the menu a few pixels or 2) set a timeout before you can choose an item from the menu (~100ms?) [1] Mostly noticed this in clearlooks because of the thin border around the menu Other information: Nautilus reverted a patch [1] to fix this issue in 2002 to be more consistent with other gnome applications. For an up to date bug against nautilus see [2] [1] http://git.gnome.org/cgit/eel/commit/?id=5ee31ee96f0b3027808026fb62a06c4593d43583 [2] https://bugs.launchpad.net/hundredpapercuts/+bug/410636
I would go with a small offset for the menu position in both axis. That is what Firefox does, that is what Qt does, and that is what Windows does.
A timeout would not solve any thing , Moving the popup menu a few pixels should be ideal
Created attachment 164695 [details] [review] Patch that solves the problem - Draft 1 The attached patch solves the problem here. I tested it with Clearlooks. I think it's sufficient to shift the menu horizontally but, of course, I'm open to better solutions.
After discussing the change on #gtk+ , requested review of the change with the accessibility team : http://mail.gnome.org/archives/gnome-accessibility-list/2010-June/msg00107.html
Looking at it from the perspective of accessibility for users who are blind.... Personally, I don't see what's so wrong about the first menu item being selected: Choose something else, exit the menu, or if you're a mouse user unselect the item by moving the mouse away from the menu. In fact, I rather like it when the first item is selected because it means one less press of Down Arrow. My personal preferences aside.... The problem I see, now that I'm looking at the issue and this bug report, is that sometimes the first item is selected and sometimes it's not. Predictability / consistency amongst instances of a given widget is a good thing for all users. Orca presents the correct information in both cases (first item selected; first item not selected). Therefore, unless someone raises some concern I've not thought of, if the Gtk+ team thinks your change is worth making the Orca team is fine with that. Thanks so much for asking, and my apologies for the delay in responding.
(In reply to comment #5) > Personally, I don't see what's so wrong about the first menu item being > selected: Choose something else, exit the menu, or if you're a mouse user > unselect the item by moving the mouse away from the menu. In fact, I rather > like it when the first item is selected because it means one less press of Down > Arrow. The most common use-case where this problem arises is for touchpad users. Once they get the context menu open , and re-touch the touchpad the item often gets selected and an undesired-action occurs. Ex: nautilus creates an unnecessary new folder > > My personal preferences aside.... > > The problem I see, now that I'm looking at the issue and this bug report, is > that sometimes the first item is selected and sometimes it's not. > Predictability / consistency amongst instances of a given widget is a good > thing for all users. > Yes ,there is some inconsistency in a few apps , earlier in nautilus they had done the menu shift themselves ,iirc it was to prevent the accidental folder being created. However they reverted the change to be more consistent with gtk+. But, a few apps might still be doing it on their own. In Firefox[non-gtk example though], the context menu item is not selected by default. This has always been its behavior. User has to move the pointer to select the first option. > Orca presents the correct information in both cases (first item selected; first > item not selected). Therefore, unless someone raises some concern I've not > thought of, if the Gtk+ team thinks your change is worth making the Orca team > is fine with that. > Thanks for reviewing the change.
Review of attachment 164695 [details] [review]: the patch looks good, but I'd rather have somebody else give a review as well. ::: gtk/gtkmenu.c @@ +49,3 @@ #define DEFAULT_POPDOWN_DELAY 1000 #define DEFAULT_POPUP_DELAY 225 +#define DEFAULT_POPUP_DISPLACEMENT 2 I would add a comment explaining what this displacement is for, and pointing to the bug.
Created attachment 165743 [details] [review] Patch that solves the problem - Draft 2 Thanks for reviewing my patch, Emmanuele. I've added a comment to the patch as you asked.
fwiw, this looks fine to me as well.
Would we have this problem if we didn't take x and y thickness into account? The xthickness and ythickness is specific to the themes, and this bug only occurs on some themes. /* position left */ x = x - requisition.width; /* position right */ x = x + 1; y = y - requisition.height; y = y + 1; The " + 1 " and the absence of " + 1 " is so the mouse position doesn't overlap the menu. This is untested, though.
(In reply to comment #10) > Would we have this problem if we didn't take x and y thickness into account? Oh , i think i just realized why we might need the xthickness. Themes can set the padding for the menu, and once that is set, the gtk probably needs adjust the menu and place it accordingly. Else if the xthickness is not specified, menu might pop-up right under the pointer instead of beside it?
(In reply to comment #11) > (In reply to comment #10) > > Would we have this problem if we didn't take x and y thickness into account? > > Oh , i think i just realized why we might need the xthickness. Themes can set > the padding for the menu, and once that is set, the gtk probably needs adjust > the menu and place it accordingly. Else if the xthickness is not specified, > menu might pop-up right under the pointer instead of beside it? Actually the xthickness for the menu is the padding inside the menu. The x position of the menu is the top left corner of the menu regardless of the padding. I have recompiled GTK+ with my edit and have tested it on my netbook, and I would say it works perfect especially in nautilus.
Looks to me like the patch will only achieve the desired effect if xthickness < DEFAULT_POPUP_OFFSET ? Also, it won't do anything for menus with a position_func afaics.
Also, looking at the gtkmenuitem menu position function, GtkMenu has horizontal-/vertical-offset style properties which we should possibly use here.
If you disregard the xthickness and ythickness, it works fine. See comment #10. I think that if there is a positioning function, then it should position it wherever the function wants without offsetting it at all. Or else it would be impossible to e.g. align it to the left/right-most edge of the screen. So in a sense, the default positioning function should have a different offset than what it is now so this bug doesn't occur. Afaik, the horizontal-/vertical-offset style properties only affect submenus right now. I agree it should probably work for GtkMenu when it's e.g. a context menu as well.
Please re-consider this solution. The displacement method that firefox uses does not work well on small screens - when ever the menu is higher than the distance from the mouse to the bottom of the screen the displacement is ignored, and accidental clicking is almost inevitable. This is especially common on small screens (think netbook - most have only 600px high screens). With a trackpad it's even worse than with a mouse, because it's difficult to click-hold-move-unclick. A delay definitely WOULD solve this for me. Simply making any button-off within the first 100ms not register would work fine, even if you were used to the click-hold-move-unclick method. Vish, why do you say that a timeout would not work? Another possibility would be to make it possible for the user to dis-allow one-click select (so that you have to right click, then make a second click to select). The last possibility is to do what Qt does, and move the menu 1px right as well. Qt also appears to calculate the height of the menu, and if it's too high, it makes the whole thing appear ABOVE the pointer, and the same horizontally, if it's too wide to appear on the right of the pointer, it moves to the left. This would also be a really good solution - it works really well on my netbook.
(In reply to comment #16) > > A delay definitely WOULD solve this for me. Simply making any button-off within > the first 100ms not register would work fine, even if you were used to the > click-hold-move-unclick method. Vish, why do you say that a timeout would not > work? > I'm not even sure you are looking at the right bug, why/what are you "holding"? Are you talking about dwell-click? The problem here is; once right-click is active it highlights the first item and users happen to easily activate it when they just touch the touchpad again, when they actually intend to get to a different menu-item. Timeout wont solve anything here, what if the user touches the touchpad after 100ms? Still same problem exists. What is the probability that all users only get back to the touchpad within 100ms of activating the right-click button? > > The last possibility is to do what Qt does, and move the menu 1px right as > well. That is what the Alberto's patch here does.. It just displaces the menu either to right or left.
>why/what are you "holding"? Are you talking about dwell-click? yes, dwell click, using the right button of the trackpad (not the trackpad itself). I get the problem that I right click, and the item is selected on button up. I assumed that that was what this bug was about, although now I re-read it I'm not so sure. >That is what the Alberto's patch here does ok, that'll probably solve my problem as well, assuming it's a different one to the original report. Sorry, I should have looked into it deeper.
I agree with comment #16, offsetting menu position doesn't solve anything, not only on small screens, but on regular screens as well, when you right-click "at the right-lower" screen conner, then the menu has no place to move on. Same as in comment #16, my highest problem is that right mouse button release selects the menu item. it's basically wrong, especially when I have set left mouse button for selection. Simple steps: a) press right mouse button, which will bring up context menu, but do not release the button b) move cursor above a menu item which will hurt the less, still with the right mouse button hold down c) release the right mouse button, the menu item is selected and the menu is gone With this you can "simulate" different positioning of the menu too. I would remove menu selection on right mouse button release completely, but if you want to keep it there, then process it only is also right mouse button down was received above the same menu item, otherwise ignore it. That's the most right thing to do, as far as I can tell. If you think this doesn't belong here (though it seems to me it does), then feel free to tell me, I'm fine to open a new bug report for this.
*** Bug 668927 has been marked as a duplicate of this bug. ***
http://www.youtube.com/watch?v=TWNflQDQcWg This bug is really annoying, Un-intended side-effects and annoyance i've been bearing because of this bug: window is minimized on right-click text is undone (undo) in gedit epiphany is going to previous page on right-click nautilus is creating 'new folders' or showing 'properties' files are opened on right click, this is real annoying, with huge archives, or isos or wine associated exe files. Please do not select the first/last item like firefox; This behavior is not GNOME Human Interface Guidelines compliant.
Okay, If we want to have 'selected' item by default. Actually I also like the default selected item, but 'execution' of the first item is an un-expected behavior. So, avoiding 'executing' the default selected item in context menu when right mouse button is released would not cause the unexpected open/properties/newfolders etcs. behavior. Here's how to see this: (in nautilus for example) 1. Right-click and keep the right-click mouse button pressed; 2. Do not release for say 1-2 seconds; hold it for a while 3. Now release the right-click button (after 1-2 seconds) 4. The right-click button release is 'executing' the first selected item (i.e., create new folder or Properties), which is an unintended behavior. for a win-win solution: 5. Preventing the 'execution' of the selected item on 1st right-click event (be it instant (10ms) or delayed 1+ seconds) will not cause the unintended launch and other actions to be performed. Please consider. Thanks.
*** Bug 683997 has been marked as a duplicate of this bug. ***
See above duplicate bug #683997, user was able to reproduce something similar also with buttons in a dialog.
I have the same problem as described in the issue, and want to share some observations. First, it is mostly happening on my Desktop with Gnome2 (Mint) and a USB mouse, in Nautilus and Chromium. It seems to be less of a problem on my notebook with clickpad and Mate desktop (Mint) I don't know about Gnome3. One interesting observation. 1. Right mouse button down -> opens context menu 2. Move a bit to the left 3. Release right mouse button -> context menu re-opens in the new mouse position! or (Nautilus) 1. Right mouse button down -> opens context menu 2. Move mouse to one of the menu options 3. Release right mouse button -> option is executed, AND the menu re-opens in the new position. This last behavior is definitely broken. Solution: For my taste, it would be ok to open the context menu only when the button is released, not on mousedown. I personally don't need the drag mechanic for right-click menus. At least this should be an option.
(In reply to comment #19) > I agree with comment #16, offsetting menu position doesn't solve anything, not > only on small screens, but on regular screens as well, when you right-click "at > the right-lower" screen conner, then the menu has no place to move on. btw, how do Apple OS and Microsoft Windows handle this right-click thing on small screen as well as in normal computer screens like 640x480+ screen resolution?
While it's a very minor issue, this behavior is annoying when switching between Windows at work and Linux at home.
I hope this bug will be fixed, because when I install gnome to some family members to which have some inexperience with the mouse, it is very annoying for them to select always the first option because they move a little to the right when they click right button. It also happens to me, so I think it is a common issue. Windows solve this forcing the user to click again to select an option after you click rigth button. I think it is the best behaviour, because as I said, some family members with mouse managing difficulties sometimes push the rigth click button for 1 second, and one second fot timeout is not a good timeout for a common user. So IMO the timout behaviour is not a good solution. For me the best solution is from comment #25, only open the context menu only when the button is released, not on mousedown.
And some thing I forgot. It happens to me and my family members with adwaita theme, the default theme, so it is not theme related for me.
*** Bug 691260 has been marked as a duplicate of this bug. ***
This is one of the worst annoyances gnome has, causing extra effort to undo what this bug of right-click button release execution is doing. Please, for anybody's sake, STOP the execution of first menu item by Right-click button release! this is the problem: 1. press right click in nautilus hold for say 1 second 2. release - 1st item executes 3. unintended "untitled folder" 4. now delete that "unintended untitled folder" [extra effort] this will be evident in epiphany/web (which I doubt anybody would seriously use as as default web browser) after login to say a bank website this right-click bug will "put you back" to login page, causing the user to type all the login details again. instead (do not make the press and hold as selection, do right click again to launch that's more natural to me, because in the first right-click I wanted to see the list, not launch an item in the list, now in the next right click I want to launch) 1. press right click for any seconds 2. release (nothing happens) (even when the first item is selected) 3. press right click again (as a confirmation) to launch selected item possible solutions: 1. move x,y axis below mouse pointer [which firefox uses] 2. increase delay to lauch an item on the mutton hold+ release say 1-2 seconds 3. holding and releasing the button for the first time will not launch the selected item. but second right-click action should on the item. 4. disable right-click action to launch I'm requesting for 3rd, 2nd will also be fine. Please this bug is really bothersome!
The severity of the bug depends on the hardware. On this ultrabook with the touchpad/buttons being all move sensitive, it's terrible. Right click wiggles the cursor a few pixels around, as if I have a motor skill disability. So moving the menu 1 or 2 pixels will not resolve anything. (this might be a driver issue?) The touchpad on my netbook with separate buttons was much less of a problem, but it was still a problem. The biggest culprits are context menus with destructive behaviour. Gedit, I'm looking at you (undo.) and browsers (back.)
(In reply to comment #32) > Right click wiggles the cursor a few pixels around, as if I have a > motor skill disability. Proof-read: there was no intention to be insensitive with this comment. It was intended to show how the bug could be more severe depending on your situation.
Created attachment 264873 [details] [review] only 1 left/right pixel displacement for menu popup, doesn't select the first item I hope The devs are ok with ONLY 1 PIXEL LEFT/RIGHT displacement. This fixes the annoyance of accidentally selecting new folder, undo, back, etc. Please consider it. Thanks. Here's the demonstration of the bug: www.youtube.com/watch?v=SuLsWRHTViQ Not only repeated right-clicking causes the bug but also Pressing and holding the right-click buttons for 1 second and releasing also causes the annoying execution of the first item (nearest to the mouse pointer) Here's Video of the patch applied: Fixes the Annoyance for good http://www.youtube.com/watch?v=zVmFUo1Nmi4 It is just 1 pixel left or right displacement. Please include this, as 1 pixel won't make any difference to desktops or even phones, touch tablets. Patch: https://www.dropbox.com/s/tkikubyzvwaju0h/gtk3-menu-displacement.patch SRPM:https://www.dropbox.com/s/yngh0174x3spjhx/gtk3-3.10.6-1.fc20.src.rpm RPMS:https://www.dropbox.com/s/9cj0mf0rr6dbgmo/gtk3-3.10.6-1.fc20.x86_64.rpm Thanks.
Link: Bug http://www.youtube.com/watch?v=SuLsWRHTViQ Link: Bug fix http://www.youtube.com/watch?v=zVmFUo1Nmi4
I just noticed recently this bug, but I can only think, why not using the CSS margin on the GtkMenu to displace the popup? margins are already meant anywhere else to add blank space around (non-toplevel) widgets, and a11y themes might set bigger margins to make popups appear farther from the click point if necessary.
See also http://unix.stackexchange.com/questions/33519/how-to-make-x-less-sensitive-when-right-clicking
Carlos Garnacho, I've seen people that will have problems with that solution. They displace the mouse more than a few pixels to just un-push his finger from the mouse, because of inexperience or because they have not a good human musculoskeletal system because of the age of because of diferent minor and major diseases. I would recommend the solution that Windows do, that is just don't triger menus on un-push, but just on push. So you have to necessarily to un-push your finger and push again to select a menu item.
Created attachment 268822 [details] RIght-click menu on gnome-shell's desktop As we can see, even gnome-shell uses "popup displacement"; which is the right behavior for a popup menu. Please notice that gnome-shell is designed for small touch screen tablets and devices along with a desktop. So, please consider popup menu displacement for gtk. Thanks.
*** Bug 673906 has been marked as a duplicate of this bug. ***
*** Bug 711760 has been marked as a duplicate of this bug. ***
I think this bug won't be fixed, there is no willingness at all by the devs to fix a usability issue since 2009, either by providing options for different user types in tweaktool or dconf or including the patches. I'm surprised to see this kind of insensibility and apathy. This is a kind of accesibility bug, I keep the button pressed for more than the delay gtk+ expects to activate the launch action, I guess 500ms? But hopefully the menus will be replaced by new popovers which don't do this annoying stupidity of selecting and launching the first item on right-click button release.
Created attachment 270979 [details] [review] gtkmenu: displace popups by their css margin I like Carlos' suggestion of using the css margin to displace the menu.
Review of attachment 270979 [details] [review]: ok. Should probably follow up with a patch to add a small margin to menus in Adwaita. Is 2px sufficient ?
I suggest it looks most elegant if you use exactly the same margin as is used between a menu separator and the item above/below it. That way a menu section will always have equal top and bottom margins -- regardless of whether the section begins/ends with a separator, or with the beginning/end of the menu as a whole.
Attachment 270979 [details] pushed as a5d5106 - gtkmenu: displace popups by their css margin
(To clarify, by "margin" in the previous comment I meant padding in the CSS sense. I looked at the patch and thought it had the definitions reversed. Using a margin solves the problem; using padding instead solves the problem and makes menus look better too.)
This is currently back in master.
bisected to https://git.gnome.org/browse/gnome-themes-standard/commit/?id=654c8f0d4278c814f23cb2413243b206e970eb21 btw The same problem already occurs with GTK+3.12.2 + HighContrast 3.12 but not Adwaita 3.12
Created attachment 280765 [details] [review] GtkMenu: Don't subtract shadow from requisition This was causing menus to show up in the wrong position in case the menu popped up towards the top and/or left.
Created attachment 280766 [details] [review] Adwaita: Add back a margin of 4px to .menu This had originally been added to Adwaita in the gnome-themes-standard commit 7bf01517bc2 but was lost during 3.13 theme changes, causing bug 591258 to reappear.
Review of attachment 280766 [details] [review]: This needs to be added to _common.scss too - the .css files are generated from that using parse-sass.sh
Created attachment 280802 [details] [review] Add back a margin of 4px to .menu This had originally been added to Adwaita in the gnome-themes-standard commit 7bf01517bc2 but was lost during 3.13 theme changes, causing bug 591258 to reappear.
Created attachment 280825 [details] [review] Adwaita: Add back a margin of 4px to .menu Forgot 'Adwaita:' in the commit message
Review of attachment 280825 [details] [review]: looks good.
Comment on attachment 280825 [details] [review] Adwaita: Add back a margin of 4px to .menu Attachment 280825 [details] pushed as 4af59db - Adwaita: Add back a margin of 4px to .menu
Attachment 280765 [details] pushed as a80e77f - GtkMenu: Don't subtract shadow from requisition
I disagree strongly with fixing this by adding a margin. What if my touchpad is so bad that the mouse jumps 5 px on right-click? Also #38! What's the Gtk+ developers opinion on removing the execute on release behavior entirely?
*** Bug 728334 has been marked as a duplicate of this bug. ***
This is still an issue (or has regressed), at least in Evolution 3.16.5 (cf. duplicate ticket against Evolution, above). When the attachment menu drop down is near the bottom of the screen, clicking the drop down button without holding it down will immediately trigger an action from the menu, without the menu ever showing. Please reopen or advise on filing a separate bug if this is considered a different issue.
I've created a new bug report about the release behaviour which would fix this one for good: https://bugzilla.gnome.org/show_bug.cgi?id=756961
*** Bug 778220 has been marked as a duplicate of this bug. ***
Bug 778220 is about the left-click behavior of the attachment button, and not about the right-click contextual menu behavior for which this bug has been filed. For the same reason, it seems that bug 728334 (comment 59) has also been wrongly marked as solved as a bug 591258 duplicate.
(In reply to Robert Andrew from comment #63) > Bug 778220 is about the left-click behavior of the attachment button, and > not about the right-click contextual menu behavior for which this bug has > been filed. What you do not see it that the code opens a popup menu after you click the button, thus it is the same issue.
(In reply to Milan Crha from comment #64) > (In reply to Robert Andrew from comment #63) > > Bug 778220 is about the left-click behavior of the attachment button, and > > not about the right-click contextual menu behavior for which this bug has > > been filed. > > What you do not see it that the code opens a popup menu after you click the > button, thus it is the same issue. Sorry for that. However this bug 591258 is marked resolved and fixed while we are still experiencing unpredictable behavior from these left-click pop-up menus in Evolution - at least in my case and Comment 60. Sometimes the hold-click will select the first available item, sometimes selection is made only after the user releases and clicks again. This happens when the pop-up menu is too long to fit between the button and the bottom of the screen and seems to depend on whether the attachment can be opened in the message body (which triggers the hold-click behavior) or not (which triggers the click-release-click behavior). Just as a guess, maybe the left-click pop-up menu inherits the hold-click behavior from the "display-in-body" button next to it? I just realized that the problem does not appear in the case of a right-click, because then the pop-up menu appears either below or above the position of the pointer according to the available space (i.e. if there is not enough space below, the menu appears above the pointer). In the case of the drop-down button, that choice does not seem to be available so the pop-up menu overlaps with the pointer if there is not enough space below, triggering the hold-click behavior.
One more clue: the problematic behavior does not happen with the button of the top bar in Evolution (neither in the main window nor in message windows). When the drop-down menu button is selected, if there is not enough space between the button and the bottom of the screen the menu appears above the button, thus avoiding the overlap problem. So for some reason the attachment buttons have a different behavior. I still have no idea though if this constitutes a separate bug to be filed either in Evolution or in Gtk+.
(In reply to Robert Andrew from comment #67) > the problematic behavior does not happen with the button of > the top bar in Evolution (neither in the main window nor in message > windows). When the drop-down menu button is selected, if there is not enough > space between the button and the bottom of the screen the menu appears above > the button, thus avoiding the overlap problem. So for some reason the > attachment buttons have a different behavior. NB: Some of the drop-down menu buttons in the top bar do not allow hold-click at all. The same could be applied to the bottom attachment buttons. Another fix might be to keep the hold-click feature but to make the pop-up menu appear above the button when not enough space is available below, to avoid overlap. > > I still have no idea though if this constitutes a separate bug to be filed > either in Evolution or in Gtk+. It seems to be an Evolution-specific implementation of Gtk+, hence my first bug report against Evolution.
Your observation is correct, you just repeat what's above already. For example comment #16. Also, what looks like a menu is not always a menu, the other buttons can be combo boxes, which behave differently. There is nothing wrong with the evolution, this is all about gtk+. Also see comment #58. Whether reopen this or not is up to the gtk+ developers.
(In reply to Milan Crha from comment #69) > Your observation is correct, you just repeat what's above already. Thank you very much for your feedback. To be sure, I don't see the point in reposting past content so I try to add new information to the best of my understanding. > For > example comment #16. Comment #16 has been answered in comment #17 and does not concern a discrepancy between Evolution buttons. But I might have missed something? > Also, what looks like a menu is not always a menu, the > other buttons can be combo boxes, which behave differently. All the buttons I mentioned are drop-down menus. For some reason, the attachment button allows hold-click but does not manage it properly. > There is nothing > wrong with the evolution, this is all about gtk+. How can we be sure? Who is implementing Gtk+ in Evolution? Who could choose to implement a different drop-down menu button, without hold-click for instance? > Also see comment #58. I am not suggesting to remove the hold-click behavior entirely, just to fix it on the one Evolution button where it messes things up. > Whether reopen this or not is up to the gtk+ developers. Of course. I hope they can give us some feedback. And again, thanks for your comments.
Chromium's UI toolkit has a little delay before releasing the right mouse button would select an option (feels like half a second or less). I think this solution would fix all cases where the hold-click feature annoys people. Would you consider such an approach for Gtk?
Thanks to comment 71, I went for further testing and it is clear now that in the Evolution case the only difference between the behavior of the attachment button in case the attachment can be displayed in the message body and the behavior in case it cannot be, seems to be the delay after which the hold-click is triggered. For whatever reason, that delay is shorter if displaying the attachment in the message body is one of the available item in the drop-down menu. What can be done from here is unknown to me though.
A short note on what seems to have the potential to fix the annoying behavior, at least for those of us who first reported in Evolution as in the duplicates from comment 59 and comment 64 above: 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. Does anyone know about 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.
Relying on the theme for such a thing is not the best idea, I'm not even sure it would work on gtk+4, shall we reopen and try different solutions?
Confirming it would hardly work on gtk+4, reopening.
See https://bugzilla.gnome.org/show_bug.cgi?id=778444 for further discussion of the newer GtkMenu properties that might help, and why they're probably safer to use than the remaining Unstable annotations suggest
*** Bug 675942 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/322.
I just want to add that the right-click menu offset problem exists also on Xubuntu 18.04 and Firefox 60 and 61. I have written more about it here: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/410636/comments/20 A wish for an added right-click behavior option to separate the double action in order to keep pop-up menu action as a separate process from also executing the menu option which ever occurs underneath the mouse courser when the right button is released.