visit that url w/ a breakpoint in nsFTPChannel::AsyncRead() and watch it get loaded twice, once from the browser and once from xul.
gagan, nominating nsbeta2
Putting on [nsbeta2-] radar. Not critical to beta2.
is this networking?
no. as I pointed out, Asyncread is being called from the browser and once from xul.
mcafee someone in don's group needs to take this. so if you are triaging his bugs reassign.
bill's been Mr. FTP lately.. over to him
Probably a derivative of the "unknown content cancels channel" problem (which I still have a bug on; this one could maybe be closed as a dup). Things are in a bit of flux at the moment. mscott added code to intercept unhandled (but "known") content *inline* (i.e., without cancelling) in order to launch helper apps. We plan to do likewise with unhandled *and* "unknown" content (content with no helper app identified yet). That would fix this once and for all. Not till beta3 though, so I'm targetting this one out a bit.
nav triage team: nsbeta3+
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
PDT looking at P2 bugs, and we don't understand what bad thing happens -- we download stuff with FTP all the time, and it only seems to download once.
if you view the FTP trace logs, it's downloading twice.
PDT believes p3. Resetting priority.
Nav triage team: We have to minus this now (minusing everything that's not P1 or P2); if this is wrong someone please alert us by removing the [nsbeta3-] from status whiteboard.
Cleaning out status whiteboard and old keywords; adding new nsbeta1 keyword to nominate this as yet another of the bugs related to unknown-content/file-download. I think this one might be fixed.
taking for qa...
nav triage team: Marking nsbeta1+
nav triage team: Putting on the backburner. Yeah, would be nice to have, but won't get to it for now. Removing nsbeta1+, marking future and p4
Bill, I though that you were cleaning this up? Should this really be futured?!
Pay no attention to the man behind the curain! This is fixed implicitly by virtue of bug 28584 (all other cases have already been fixed).
I voted to keep this, lost the vote. Hope law's got that balloon ready to take off. Which way to Kansas!?
nav triage team: Marking nsbeta1-, not a beta stopper
*** Bug 75320 has been marked as a duplicate of this bug. ***
Clearing nsbeta1- for re-evaluation, and adding perf keyword. Fixing this would _halve_ the time taken to display the initial ftp (and gopher) url, because the ftp control connection appears to be set up again for the second time. It is the second loading which causes data to be displayed, and the second loading doesn't start until just before the first one is finished. See bug 75320 for NSPR logs. Bug 28584 is mentioned as fixing this, but that doesn't seem relevent.
I will fix this for 0.9
->dougt, then. :)
this is alot of work. pushing out milestone.... sorry.
C8 H10 N4 O2 Not that much work. I have a patch.
Created attachment 31325 [details] [diff] [review] Fixes FTP double loading inital directory listing.
maybe we can get this into 0.9? Bradley, please review. Chris, please give me some sr props.
*** Bug 76276 has been marked as a duplicate of this bug. ***
nsCOMPtr<nsIChannel> channel = do_QueryInterface(request); would you consider channel(do_Query...) syntax?
r=bbaetz on the updated patch (not that I hated the previous one... :-)
waterson has sr'ed a=drivers lets get his in if its ready to go.
Fix checked in.
VERIFIED: I'm using Mozilla 0.9 allplats, in w/ the directory (tree) viewer, and I'm not getting double requests.