GNOME Bugzilla – Bug 102666
Popup menus should appear beside object, not under mouse
Last modified: 2018-01-30 15:24:46 UTC
From a recent review by a Sun beta tester: "When the keyboard is used to display a popup menu, the menu is positioned under the hotspot of the pointer, regardless of where the pointer is located on the screen. If the keyboard is used to display a pop-up menu, the menu should be placed to the right of the object, rather than at the pointer location." This is particularly distracting for people who use screen magnifiers etc.
Need more information. I believe all or most-all pop up menus in GTK+ position correctly when activating by the keyboard. (In particular, the GtkTextView and GtkEntry popups.) In general, for any other app, it's the apps responsibility to position menus corrrectly. E.g., if nautilus pops up a menu for an icon, only nautilus really knows where to put the menu.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Calum, Do you have any information about what applications or menus are being complained about? If not, we might as well close the bug.
I am transferring to nautilus as one case I have found for this is popping up the context menu for an icon in the icon view. It appears near the mouse
I see the problem when invoking the popup menu in 1. list view 2. icons in the desktop i.e. when I do a shift+F10 on any item on the list view or in the desktop icons, the popup menu is placed beside the cursor. Thanks.
Still here in nautilus 2.7.2.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Calum: Maybe you could make a mockup where exactly you want them to be placed? For the tree view, below the selected items (like with the panel applets), right? What about the icon view? You said you want the menu on the right of the icon. Where should the top border of the menu go?
Calum?
Christian: when working with Calum to establish placement, also please make sure the popup appears inside the _NET_WORKAREA in these cases.
Bill: Only for the desktop or for all nautilus views?
Christian: All, I suppose, because if you don't observe WORKAREA you can pop the menu up on top of the onscreen keyboard or magnifier.
Sorry, missed the ping on this first time around... will have a think about it this week.
Calum: Did your pondering result in any rationale?
Well, some observations at least. I had a look at what Windows does, here's the summary: Icon view: top-left corner of menu is approximately in the centre of the icon. List view: again, top-left corner of menu is approximately in the centre of the icon in the left-hand column. Sidebar tree view: top-left corner of menu appears horizontally-centred on the filename, and approximately one or two characters from the left. (Not sure why it couldn't just be in the centre of the icon, again). Macintosh still doesn't, AFAICT, have any way of displaying popup menus from the keyboard, so I couldn't check to see what it does. So anyway, having the top-left corner of the menu appear in the centre of the last object selected (so that it works in multi selection cases too) seems like a reasonable first attempt at a guideline to me. Of course, as with dropdown menus, the position may need to be adjusted on the fly so that it fits on the screen. (Or as Bill points out, the _NET_WORKAREA.) Note that this problem isn't unique to nautilus; if you focus an object on the panel and hit Shift-F10 or Ctrl-F10, for example, the popup menu appears under the pointer too. (I'm guessing the _NET_WORKAREA restriction will cause things to look a little odd with panel popups too, since panels lie outside the workarea, right? So the popup menu won't actually overlap the panel as it normally would if you just right-clicked.) I guess I need to file a separate bug against the panel for that though :)
*** Bug 314600 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Adding API to gtk+ to get popup windows to be placed within the valid workarea is filed as bug 329491; once that is fixed it'll help fix this bug. :)
*** Bug 344032 has been marked as a duplicate of this bug. ***
Still valid. It seems that the function 'nautilus_pop_up_context_menu' in nautilus-ui-utilities.c always calls 'gtk_menu_popup_at_pointer' even if button event is NULL, that is, when the popup menu is triggered by the "popup-menu" signal due to using the <menu> or <shift>+<F10> keyboard shortcuts. The code seems to follow the example from https://developer.gnome.org/gtk3/stable/gtk-migrating-checklist.html#checklist-popup-menu However, as noted at the end of that example: > If you do not pass a positioning function to gtk_menu_popup(), it will show the menu at the mouse position by default. This is what you usually want when the menu is shown as a result of pressing a mouse button. However, if you press the Shift+F10 or Menu keys while the widget is focused, the mouse cursor may not be near the widget at all. In the example above, you may want to provide your own menu-positioning function in the case where the event is NULL. However, gtk_menu_popup() is deprecated, so the offered solution is outdated. So, my guess is that 'nautilus_pop_up_context_menu' should call 'gtk_menu_popup_at_rect' if event is NULL.
Created attachment 358176 [details] [review] ui-utilities: Don't always popup menu on pointer position This is by far the most complex patch I've ever made, so please review carefully and watch out for crass newbie errors, especially with relation to memory management.
(In reply to António Fernandes from comment #22) > Created attachment 358176 [details] [review] [review] > ui-utilities: Don't always popup menu on pointer position > > This is by far the most complex patch I've ever made, so please review > carefully and watch out for crass newbie errors, especially with relation to > memory management. Bug 773154 already has patches to address the issue.
Oh, so I didn't search well enough before. Also, my patches have a lot of review comments to address, and I never got back to them yet... maybe António's are closer? If so, feel free to mark my copy as a dupe of this one, if it offers nothing additional in the end.
Review of attachment 358176 [details] [review]: As mentioned in IRC, better to figure out if we can have the selection list in order of time they were selected, so we can actually know what was the last item selected and popup the menu in there
*** Bug 773154 has been marked as a duplicate of this bug. ***
Let's mark mine as the duplicate it is, and refer back to the patches/reviews if there's anything useful there. i.e.: if somehow no one else beats me to finally fixing the bug. :P
(In reply to Carlos Soriano from comment #25) > As mentioned in IRC, better to figure out if we can have the selection list > in order of time they were selected, so we can actually know what was the > last item selected and popup the menu in there I don't think we can for List View without new Gtk+ API. The GList of selected items is given by gtk-tree-selection-get-selected-rows, which seems to return them in the view order. -- This is what MS Windows 10's File Explorer does in this situation: 1) Popup from the item with keyboard focus, if part of selection. This is a very clever idea. Also, it's likely to be the last item selected. 2) If the item with keyboard focus is not part of the selection element, popup from first item in the selection. A clever fallback, but, as argued in bug 773154, the last item would be better. 3) In both cases, is the item to popup from is out of view, menu pops up from top right corner of the view. Now, this is just dumb. It pops up from the top of the view even if the selection is downwards. It doesn't even try to scroll selection into view, not even if only 1 item is selected. -- It seems easy to implement 1) and 2), and Daniel patches already have a better solution for case 3), by scrolling the selection into view. What do you think, Carlos?
*** Bug 579872 has been marked as a duplicate of this bug. ***
Just an update, in our discussion in IRC we decided the best approach and more logical is to save the selection by time order, instead of by view order. Once we have that, we can popup the menu in the last item selected.
This has been fixed by commit 29cf64bd7632b25dd56a275078da6130b201edeb https://gitlab.gnome.org/GNOME/nautilus/commit/29cf64bd7632b25dd56a275078da6130b201edeb
Awesome, thanks for that! I don't know when I would've gotten around to look at that patch set again...
Thanks to you too, your existing work was a great source of inspiration, and reading the reviews too.