URIs, D&D and bug #48423

[Michael Meeks <michael ximian com>]

Hi there,

	I was wondering what the status of this comment:

nautilus-dnd.c (add_one_compatible_uri):

/* Encode a "text/plain" selection; this is a broken URL -- just
 * "file:" with a path after it (no escaping or anything). We are
 * trying to make the old gnome_uri_list_extract_filenames function
 * happy, so this is coded to its idiosyncrasises.
 */

	Is. I ask this because in bug #48423, we blindly accept that the
incoming URI in the D&D list is in fact a URI, and not a mangled
filename. And we emit a 'location_changed' signal with it as the string,
all of which ends up doing:

#6  0x40057e0b in nautilus_directory_add_file (directory=0x8287430,
file=0x8106588) at nautilus-directory.c:577
#7  0x40063548 in nautilus_file_get_internal (uri=0x8423e08
"file:/home/michael/foo/untitled folder 1", create=1)
    at nautilus-file.c:359
#8  0x40063598 in nautilus_file_get (uri=0x8423e08
"file:/home/michael/foo/untitled folder 1")
    at nautilus-file.c:379
#9  0x0805f1f3 in nautilus_determine_initial_view (
    location=0x8423e08 "file:/home/michael/foo/untitled folder 1", 
    callback=0x807a9c0 <determined_initial_view_callback>,
callback_data=0x8288f80)
    at nautilus-applicable-views.c:156
#10 0x0807b010 in begin_location_change (window=0x8288f80, 
    location=0x8423e08 "file:/home/michael/foo/untitled folder 1",
type=NAUTILUS_LOCATION_CHANGE_STANDARD, 
    distance=0) at nautilus-window-manage-views.c:1435
#11 0x08079f91 in nautilus_window_open_location (window=0x8288f80, 
    location=0x8423e08 "file:/home/michael/foo/untitled folder 1") at
nautilus-window-manage-views.c:715
#12 0x409244d9 in g_cclosure_marshal_VOID__STRING (closure=0x8448420,
return_value=0x0, n_param_values=2, 
    param_values=0xbfffe210, invocation_hint=0xbfffe118,
marshal_data=0x0) at gmarshal.c:496
#13 0x4090ef7a in g_closure_invoke (closure=0x8448420,
return_value=0x0, n_param_values=2, 
    param_values=0xbfffe210, invocation_hint=0xbfffe118) at
gclosure.c:437
#14 0x40922eb3 in signal_emit_unlocked_R (node=0x81ea790, detail=0,
instance=0x8458750, emission_return=0x0, 
    instance_and_params=0xbfffe210) at gsignal.c:2341
#15 0x40921652 in g_signal_emit_valist (instance=0x8458750,
signal_id=187, detail=0, var_args=0xbfffe3a0)
    at gsignal.c:2100
#16 0x409218cf in g_signal_emit (instance=0x8458750, signal_id=187,
detail=0) at gsignal.c:2144
#17 0x08071efb in receive_dropped_uri_list (sidebar=0x8458750, x=82,
y=226, selection_data=0xbfffedf0)
    at nautilus-sidebar.c:735
#18 0x0807229f in nautilus_sidebar_drag_data_received
(widget=0x8458750, context=0x84dde50, x=82, y=226, 
    selection_data=0xbfffedf0, info=0, time=4082867813) at
nautilus-sidebar.c:892

	Which for the un-initiated means that this unescaped (%20 for spaces)
URI goes into the nautilus-directory as a separate entry from the
(pre-existing) properly escaped entry of the same name.

	What should be done about that ? would a correct fix be to use
eel_make_uri_from_input on the incoming URIs ?

	Regards,

		Michael.


-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot