GNOME Bugzilla – Bug 337588
Dropping an url on the desktop, doesn't make a bookmark
Last modified: 2006-04-10 20:10:58 UTC
Please describe the problem: In gnome 2.10 when dropping an url on the desktop (eg. dragging a firefox tab) it would make a bookmark. In gnome 2.14 it only makes a "new file" text file, with the url written inside it. Steps to reproduce: 1. Open a page in firefox 2. Drag a tab to the desktop Actual results: "new file" text file appears, with the url written inside it. Expected results: A bookmark file, with the name = the title of the url, should appear Does this happen every time? Yes Other information:
Weird... cause if you actually drag the little icon next to the url, you get a bookmark just fine. I think this is actually a bug in Firefox where it doesn't send out the same thing on dragging the icon compared to dragging a tab. Please file it at the Firefox Bugzilla... As to whether or not to parse dragged files to see if they are URL:s and making links out of them? I'm not really sure how that would be done... Looking up the actual page just to grab the title seems a bit overkill...
Well yea, that's quite weird :S And when I drag into gedit, exactly the same thing is appearing. Is there any place to drag them, to find out what data is really being parsed? About the title, the bookmarks made from dragging the little icon, gets the title quite well.
The "link to ..." item gets added when a "_NETSCAPE_URL" drag is received. If a drag source provides both, "_NETSCAPE_URL" and some plain text drag target, the order in which Nautilus will query the target is precisely the order in which the targets have been registered (cf. get_data_on_first_target_we_support from nautilus-icon-dnd.c). If the drag source registers the "_NETSCAPE_URL" target before the plain text target, it will be preferred over the text target. The Epiphany location entry seems to offer "text/uri-list", "_NETSCAPE_URL" and "text/plain", in that order, so that one works because the URL targets preceed the text targets. http://www.newplanetsoftware.com/xdnd/ suggests that target type precedence should be determined by the target, not by the source, i.e. we should ask for URI targets before text targets: > data.l[2,3,4] contain the first three types that the source supports. Unused > slots are set to None. The ordering is arbitrary since, in general, the source > cannot know what the target prefers. So get_data_on_first_target_we_support should be rewritten to iterate through the targets and ask the source for the respective target, IMO. This has to be implemented both for the icon view and the list view. Volunteers? :)
Created attachment 63021 [details] [review] Proposed patch Disucssion: http://mail.gnome.org/archives/nautilus-list/2006-April/msg00026.html
2006-04-10 Martin Wehner <martin.wehner@gmail.com> * libnautilus-private/nautilus-icon-dnd.c: (get_data_on_first_target_we_support): Determine drop target by iterating through drop container target list instead of drag context DND list. (#337588) Patch from Christian Neumair <chris@gnome-de.org>