GNOME Bugzilla – Bug 354307
Dragging URL to Nautilus with non-standard port makes Nautilus hang
Last modified: 2011-12-01 22:45:04 UTC
Please describe the problem: Dragging a URL to Nautilus (From the address bar, a hyperlink, etc. -- specifically from Firefox, but probably from other browsers as well) will cause Nautilus to hang if that URL contains a non-standard port number. E.g. http://example.com:1234/. Nautilus then needs to be killed from a terminal. Steps to reproduce: 1. Visit a web site hosted on a non-standard port number. 2. Click and drag the favicon from the address bar (or alternatively drag a hyperlink) to a Nautilus window or the desktop. Actual results: Nautilus freezes until killed; stops redrawing its windows or the desktop icons when another window moves over them, etc. Expected results: A "link to [page title]" file should be created. Does this happen every time? Yes. Other information:
Thanks for the bug report. Without a stack trace from the crash it's very hard to determine what caused it. Can you provide us with one? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
Created attachment 72974 [details] Stack trace Here's the stack trace. I left nautilus running for a few minutes after reproducing this, hoping it would stop by itself, but ended up having to kill it from a terminal. Also worth mentioning that I recently upgraded to Ubuntu Edgy, so this happens in Gnome 2.16 as well as 2.14.
Stacktrace? This is a hang, not a crash. No need to ask for a stacktrace... Anyway, the stacktrace of the hanging app even has been provided. Thanks Adam. REOPENing.
+ Trace 72747
encoded_url looks suspicious to me. I was not able to trigger the crash. I typed the address into firefox but I cannot dnd it to nautilus. Can you give us instructions?
Try dragging the link from this page to Nautilus; http://example.com:1234/ Interestingly, now that I try this with some other URLs I get different results. Some URLs work as expected (e.g. http://www.ducksong.com:81/dccp/ ), others fail to create the link on disk but do not hang Nautilus (e.g. https://one.valcatohosting.com:2083/ ), and the example I gave above hangs Nautilus until it is killed.
Hmm so after fiddling around I double-klicked the typed-in URL and dnd it to nautilus; It creates a new text file with the URL in it. No hang. I run Gnome 2.14.3 what is your version of nautilus (help->about)?
Currently running 2.16.0, was running 2.14.3 when I first reported this. If you're going to drag it from the URL bar, you need to drag the icon at the left hand side of the URL rather than the URL itself (or the icon on the left hand side of any tab in the tab bar). Also works if you drag the link directly from a page without visiting it first (i.e. click, hold, and drag the links in my previous message on this page).
Strange, even in firefox2 I cannot dnd the icon in the URL text field into nautilus. The icon is not draggable for me.
Using firefox2 and nautilus 2.16.1 i was unable to reproduce. When I dragged the text, it created a text file in my directory.
I would like to confirm that it happens on my machine too (I shouldn't have tried it!). For those who cannot reproduce, you might try dragging from URL directly (do not make the selection, just put your mouse on URL and drag it as it is an object)
Confirming it with 2.22.0.
From a gvfs point of view there is not much we can do here. We should probably have a timeout for connect though, but that still woudn't solve the issue. One needs to patch nautilus to not do sync IO.
Created attachment 107744 [details] [review] patch In 2.22.0 this actually happens because of two bugs: 1) is a Nautilus one, as it does sync I/O to query info for the dropped uris. Attached patch reworks that code path by making it async and a bit more robust. 2) is a GVfs one, as when we query for e.g. http://example.com:1234, the GVfs http backend does not answer with a G_IO_ERROR_HOST_NOT_FOUND or sth similar, but doesn't answer, letting the request timeout on the bus. This is a big issue if we do sync I/O, as it freezes Nautilus for the timeout period (30 seconds I think), a smaller one if we do it async, but it's ugly to have to wait 30s to finish the task.
Cosimo: Thanks for working on this issue! Some comments on the patch: A) You seem to override the uri_list variable in finish_handling_netscape_url_drop() in a local if() block. Please either remove the function-wide definition, or remove the local one. B) In query_info_callback(), you should free the drop data if the action == 0 case. C) In fm_directory_view_handle_netscape_url_drop(), you should unref f after querying the file info. D) You should also ref/unref the data->view [possibly using a weak ref], otherwise you may access invalid memory if the view is destroyed before the file info has been fetched. Otherwise, I like the approach. Marking attachment 107744 [details] [review] as "needs-work".
Is this bug still an issue?
Yes, the patch needs to be updated.
I finished this some time ago and forgot to close the bug.
*** Bug 556846 has been marked as a duplicate of this bug. ***
*** Bug 636472 has been marked as a duplicate of this bug. ***