Re: URIs, D&D and bug #48423

[David Emory Watson <dwatson cs ucr edu>]

Good catch Michael!  :) This bug is seriously annoying.

On Tue, 2002-05-21 at 10:41, Michael Meeks wrote:
> 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
> 
> -- 
> nautilus-list mailing list
> nautilus-list gnome org
> http://mail.gnome.org/mailman/listinfo/nautilus-list
>