GNOME Bugzilla – Bug 519020
nautilus performs context menu action on wrong file
Last modified: 2021-06-18 15:18:16 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/194726 "nautilus 1:2.21.91-0ubuntu3 steps to reproduce. put a large file in you home folder, an 700mb ISO works well. make a new file on your desktop, anything will do. i'll call it foo.odt initiate a copy of the large file to you desktop (drag and drop with CTRL held down) while the copy progress bar is visible right click on foo.odt, keep the context menu open until the copy of the large file is complete. now choose one of the actions in the context menu (eg move to trash) the action is carried out on the copied large file! i would expect it to happen to the file that i right clicked on. it seems that when the the copy operation finishes the the newly copied file becomes selected, and hence the context menu applies to it. it can also be triggered if you download a file by dragging from a webbrowser to you desktop."
Created attachment 106064 [details] [review] Proposed patch This patch fixes the issue at least for selection changes due to file operations. I'm not sure about other selection changes - I didn't want to modify fm_directory_view_set_selection() to always do nothing if the pointer is grabbed. In some places functions using that API may expect that the view's selection is reliably modified, for instance if it is carried out from a grabbed widget's method.
Its kinda weird to look at whether the the pointer is grabbed for this, as its is a global state which is affected by other apps too (i.e. some other menu could be open) leading to surprising results. It seems to me that we should just make sure the context menu is either updated or at least closed when the selection changes.
> It seems to me that we should just make sure the context menu is either updated or at least closed when the selection changes. I think as a user I'd really expect that the action is carried out on the files I selected. I'm CCing the usability team for some qualified opinions. best regards, Christian Neumair
Oh, gdk_display_pointer_is_grabbed() is an X roundtrip too, so its very expensive. It is kind of a corner case, and while I agree that if you select something and then some random issue happens it shouldn't silently use the new files as target. I guess if we update the menu sometimes you might not even notice, so that is maybe a bad idea. However, its also kind of weird that after the selection change the context menu doesn't work on the current context (i.e. selection). So, maybe the best thing is just to close an open context menu when the selection changes. This is after all not a common thing, and while its sort of weird to the user at least there is zero risk of doing the wrong thing.
This is still a problem in 2.32.2.1
Comment on attachment 106064 [details] [review] Proposed patch Marking as 'rejected' as per Alexander's comment.
Mass component change due to BZ cleanup, sorry for the noise.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.