I tried to use mozilla to get a daily build from ftp.mozilla.org I got as far as the saving file dialog, but it never progressed. I got stuck at 0%. I'll attach the screen shot of the dialog at where it stopped.

FTP is downloading the data (check for the file after hitting cancel on the dialog (after you think it's done ;). It's just not propagating status. Bill, where does your dialog get progress info?

jud is right. the file appeared to be download. I save it as foo.tar.gz ls -al foo.tar.gz -rwx------ 1 seth seth 5203264 Nov 4 12:13 foo.tar.gz the progress never changed and it never went away, when it finished. but it looks like it did download the whole beast!

file download is being overhauled to deal with the Necko-ized world properly.

This code was written to the old netlib notification mechanism (nsIStreamListener, I think). The OnProgress notifications now go out to the nsIProgressEventSink. This was added as a base class to the nsStreamXferOp class but unfortunately, there's no nsIEventSinkGetter that will return this progress event sink. Actually, it's even worse. When this code is overhauled to be fully necko-fied, it won't even be doing the channel creation (at which point one can provide an event sink getter). There are further obstacles to putting in place the "correct" implementation (namely, the inability to obtain an input stream from an http channel). It's also not clear if passing the input stream to AsyncWrite will be possible while still getting the OnProgress. Anyway, the current implementation I'm working on (much more like the ultimate solution but with workarounds for the current obstacles) manages progress notifications by simulating them from the stream listener's OnDataAvailable. I'm still battling two problems: 1. saving files coming via ftp doesn't work right. I diagnosed one problem; was due to ftp passing a proxy channel to OnStartRequest/OnStopRequest, which threw off my code (I was expecting the same channel I did the AsyncRead on). But it's still hanging. 2. leaking; my object gets referenced from both the input and output channels/streams and something is not letting go; may be proxy related. ftp download in general is tracked by bug #10737 so I'm making this one a duplicate of that. *** This bug has been marked as a duplicate of 10737 ***

I don't think of this bug as a duplicate of that. Bug 10737 means get basic ftp support working. This bug is really unrelated to ftp. I think you have the exact same problems trying to save http, file, etc. links, right?

Clearing DUPLICATE resolution due to re-open.

Updating component from Browser-General to Necko.

The dialog is now showing progress and completion (modulo other bugs).

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

old bug - FTP has been working for some time now