This isn't strictly ftp - it happens for gopher as well. But since I copied the code to do this from the ftp code, it may be. ccing waterson as the nsDirectoryViewer person. If you type ftp://ftp.mozilla.org into the url bar, then the url gets fetched from the network twice. In the case of ftp.m.o the control connection is created and torn down each time. For ftp://localhost/, the control connection is reused, but the actual listing still occurs twice. I have verified that this occurs by using ethereal, and I'll be attaching a log with NSPR_LOG_MODULES=nsFtpProtocol:5. The XXX and *** lines are debugging printfs I've added to nsDirectoryViewer.cpp at the top of the respective routines (I found this while working on bug 70529, although this happens without my patches - ie its not my bug). It looks like we're getting the listing, then working out that we need the dir viewer. We then create the viewer, and it tries to get some new data, rather than using what we already have. I tried to look into this, but didn't really get anywhere - I don't really understand how everything connects up. dougt: This does not happen with the html directory listing, and if we do (as it appears from the log) download the entire directory listing before even loading up the xul, this could go a long way towards explaining why the html viewer is so much faster.
This is definately a performance issue. :) Nominating for nsbeta1 as well.
damn directory viewer.... I will look at fixing this...
This is probably dup of bug 45066. And could someone point me to similar bug on HTTP protocol? When I am browsing on some sites (esp. sourceforge.net) it sometimes enters the url twice into the history so I have to press back button twice if I want to get back. Also on the console there is printed some error twice: Error loading URL http://sourceforge.net/projects/asd: 804b0002 Error loading URL http://sourceforge.net/projects/asd: 80520012
Yeah, this is a dupe. nsbeta1-?? Bah. I'll renominate it. The http error could be 74318, possibly. Although you have different error codes. It could be a history related bug, though. *** This bug has been marked as a duplicate of 45066 ***
VERIFIED: Behavior is the same as the original duplicate.