GNOME Bugzilla – Bug 775860
Drag&drop broken, fails to transfer files, invokes "add bookmark" in sidebar, locks its state
Last modified: 2021-06-18 15:52:41 UTC
There is a common bug on Fedora 25 related to drag and drop. Reproducible: Not on will, but happens quite often. I see it like 3 times per week. Affected versions: nautilus 3.18, 3.20, 3.22 Steps to reproduce (doesn't work 100%): 1. open a nautilus window 2. drag some files, but don't drag them to the sidebar 3. drop them somewhere to get them copied or moved 4. wait for copy/move action to happen 5. after some time, close the application What happens: At 2, you can see the "Add bookmark" button. It does never hide again until nautilus process exits. At 4, the files won't be moved immediately, instead nothing happens. After a while (10…30 seconds) you'll get a notification that the file could not be copied. At 4 or 5, nautilus crashes. See the many ABRT backtraces below. What should happen: Immediately copy files, or – if that's not possible – immediately show why it doesn't copy files. When the drop happened, hide the "Add bookmark" button. Additional info: Every time I run into this bug, nautilus crashes afterwards (takes some time, often it crashes when closing). Some of these bug reports are reported to Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1375468 https://bugzilla.redhat.com/show_bug.cgi?id=1388952 https://bugzilla.redhat.com/show_bug.cgi?id=1388954 https://bugzilla.redhat.com/show_bug.cgi?id=1253980 https://bugzilla.redhat.com/show_bug.cgi?id=1291898 https://bugzilla.redhat.com/show_bug.cgi?id=1272642 [abrt] nautilus: nautilus_list_model_get_all_iters_for_file(): nautilus killed by SIGSEGV Fedora 23: https://bugzilla.redhat.com/show_bug.cgi?id=1285736, https://bugzilla.redhat.com/show_bug.cgi?id=1299120 Fedora 24: https://bugzilla.redhat.com/show_bug.cgi?id=1377066 Fedora 25: https://bugzilla.redhat.com/show_bug.cgi?id=1398439
This issue might be specific to wayland. I don't know if these pieces of information are related: * I'm getting a warning every time nautilus moves a file or folder via drag and drop: Gtk-WARNING **: You must override the default 'drag_data_delete' handler on GtkTreeView when using models that don't support the GtkTreeDragSource interface and enabling drag-and-drop. The simplest way to do this is to connect to 'drag_data_delete' and call g_signal_stop_emission_by_name() in your signal handler to prevent the default handler from running. Look at the source code for the default handler in gtktreeview.c to get an idea what your handler should do. (gtktreeview.c is in the GTK source code.) If you're using GTK from a language other than C, there may be a more natural way to override default handlers, e.g. via derivation. * The downstream metadata suggests that this bug is not specific to wayland. * I often get this warning if I cancel a drag-n-drop by dragging the file back to where it comes from (numbers vary, of course): (nautilus:3052): GLib-CRITICAL **: Source ID 3008 was not found when attempting to remove it * Valgrind shows some interesting backtraces for memory access errors which really should not happen, e.g. this: ==3052== Conditional jump or move depends on uninitialised value(s) ==3052== at 0x1DA8E5: drag_motion_callback (nautilus-tree-view-drag-dest.c:610) ==3052== by 0x6B273D6: _gtk_marshal_BOOLEAN__OBJECT_INT_INT_UINT (gtkmarshalers.c:809) ==3052== by 0x88833E4: g_closure_invoke (gclosure.c:804) ==3052== by 0x8895431: signal_emit_unlocked_R (gsignal.c:3635) ==3052== by 0x889DB8E: g_signal_emit_valist (gsignal.c:3401) ==3052== by 0x889E8EA: g_signal_emit_by_name (gsignal.c:3487) ==3052== by 0x6CA0017: gtk_drag_dest_motion (gtkdnd.c:1564) ==3052== by 0x6CA06CF: gtk_drag_find_widget (gtkdnd.c:1262) ==3052== by 0x6CA06CF: _gtk_drag_dest_handle_event (gtkdnd.c:1083) ==3052== by 0x6B25339: gtk_main_do_event (gtkmain.c:1908) ==3052== by 0x7237484: _gdk_event_emit (gdkevents.c:73) ==3052== by 0x7292E51: gdk_event_source_dispatch (gdkeventsource.c:118) ==3052== by 0x8B0FE41: g_main_dispatch (gmain.c:3203) ==3052== by 0x8B0FE41: g_main_context_dispatch (gmain.c:3856) ==3052== ==3052== Conditional jump or move depends on uninitialised value(s) ==3052== at 0x1D9C74: get_drop_target_uri_at_pos (nautilus-tree-view-drag-dest.c:714) ==3052== by 0x1DA2D4: receive_uris (nautilus-tree-view-drag-dest.c:748) ==3052== by 0x1DA2D4: receive_dropped_icons (nautilus-tree-view-drag-dest.c:815) ==3052== by 0x1DA2D4: drag_data_received_callback (nautilus-tree-view-drag-dest.c:1005) ==3052== by 0x6B2CE73: _gtk_marshal_VOID__OBJECT_INT_INT_BOXED_UINT_UINT (gtkmarshalers.c:5511) ==3052== by 0x88833E4: g_closure_invoke (gclosure.c:804) ==3052== by 0x8895431: signal_emit_unlocked_R (gsignal.c:3635) ==3052== by 0x889E05E: g_signal_emit_valist (gsignal.c:3391) ==3052== by 0x889E8EA: g_signal_emit_by_name (gsignal.c:3487) ==3052== by 0x6C9F1BC: gtk_drag_selection_received (gtkdnd.c:1181) ==3052== by 0x88833E4: g_closure_invoke (gclosure.c:804) ==3052== by 0x8895431: signal_emit_unlocked_R (gsignal.c:3635) ==3052== by 0x889E05E: g_signal_emit_valist (gsignal.c:3391) ==3052== by 0x889E8EA: g_signal_emit_by_name (gsignal.c:3487)
Also happens in an X session but with much less frequency, and the only reason that I notice it is because I was aware of this annoyance in Wayland which happens very frequently. The following might be related as evince seems to trigger the issue and fuck up input focus https://bugzilla.gnome.org/show_bug.cgi?id=767136
This also Occours on nautilus 3.24.1 Wayland. There also seems to be a large delay between the drop and paste operation but I don't think the bugs are related.
(In reply to Vyas Giridhar from comment #3) > This also Occours on nautilus 3.24.1 Wayland. > There also seems to be a large delay between the drop and paste operation > but I don't think the bugs are related. It doesn't occur always though.
Is this bug still happening with versions 3.26 or 3.28? (In reply to Vyas Giridhar from comment #3) > There also seems to be a large delay between the drop and paste operation > but I don't think the bugs are related. This delay has been reported as https://gitlab.gnome.org/GNOME/gtk/issues/211
(In reply to António Fernandes from comment #5) > Is this bug still happening with versions 3.26 or 3.28? I've seen it a lot with 3.26 but I can't remember having seen it on 3.28.
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.