No directories or anything is showing up when I try to load ftp://ftp.netscape.com or ftp://sweetlou or whatever on the Mac. It is treated almost like a bad URL. This is using 9/22 builds. On linux and windows95, ftp://ftp.netscape.com loads the directory structure correctly.

Subject: Re: Mac FTP debugging help Date: Mon, 27 Sep 1999 22:03:00 -0700 From: Warren Harris <warren@netscape.com> To: Simon Fraser <sfraser@netscape.com> CC: Brendan Eich <brendan@meer.net>, pinkerton@netscape.com, valeski@netscape.com, gagan@netscape.com References: 1 , 2 Thanks Simon. Tomorrow might be a little tight, but I'll try to drop by. Meanwhile, here's how you can reproduce it: Set a breakpoint in nsFtpConnectionThread::Process on the switch statement (in netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp in the ftp dll/component). Then go to an ftp URL like ftp://ftp.netscape.com. You'll see that the ftp connection thread doesn't wake up for quite a long time (maybe 2 minutes), and when it does, the connection is always closed, so it fails. Now the failure mode is a little screwed up unless Jud has fixed it, but you can set a breakpoint in nsFtpConnectionThread::R_list in the same file, in the if statement after the Read call. You'll see Read return 0 (meaning EOF) before it gets any data. Call Jud for help too: 303-546-0061 Warren Simon Fraser wrote: > Brendan Eich wrote: > > > > Hey pink, necko guys need a little event/thread-level debugging help > > on the Mac to figure out why ftp sucks there. If you can't help 'em > > cuz you're maxed out elsewhere, can you nominate someone for me to > > bug? From what I hear, it might be some intensive debug sessions but > > not days worth of time. > > > > Maybe I should be asking sfraser, cuz he's on the Time team. > > I can look at this with warren, if he'd like to wander over to my cube > sometime. > > Simon

Here's the basics of what happen here: The main FTP connection opens fine (if a little slowly, because of some timeout that happens on Mac when USE_POLLABLE_EVENTS is off. This connection gets as far as the LIST command, whence it spawns the second passive FTP connection. This second connection never completes the connection stage; it just sits there until a disconnect. After talking to gordon, I have a suspicion that this is because of the USE_POLLABLE_EVENTS stuff that does not work on Mac. Could it be that having two connections on the same thread results in one of them not getting serviced? I'm going to reassign this bug to gordon, because you have a better chance of understanding this than I do. Also ccing rpotts, who knows about the USE_POLLABLE_EVENTS.

The fact that sfrasier is seeing successful reads/writes on the command channel indicates that there's a problem w/ > 1 connections (in blocking mode at least) on the same thread on the mac.

ugh. we're seeing some interesting behavior. fraser and I watched ftp work just fine (dir listing's showed up and we downloaded a file) this morning :\. In my windows build I built w/ out USE_POLLABLE_EVENTS defined (as mac does) and things worked. I don't think this means it's not the culprit on mac (because mac threading is certainly implemented differently anyway), but I just wanted see what would happen if I turned them off for windows.

Oh this is a great bug. I just used the same mac build that was failing yesterday, and was able to view directoreis without incident. I saw some sporratic behavior at ftp.microsoft.com (I was asked to authenticate when I shouldn't have been). I'm thinking that the state machine is somehow getting whacked on the mac, or the ftp connection thread isn't being initialized properly.

I'm able to view directories and download files with the latest version of AppRunner. There is still a problem after the file download has been completed, the progress dialog doesn't go away, but this behavior is identical on all platforms. Bill Law indicates it is related to an xpconnect bug.

This only sorta works on the Mac. For the MacOS86 1999120608 mozilla build, the first time you enter an ftp url, it works fine. If you try to drive deeper into the url (by typing in the location field) or if you attempt to go to a different url (i.e. ftp://sweetlou/ then ftp://ftp.netscape.com), there is no visible or functional response from the browser. To put it another way, the browser doesn't appear to be able to load more than one ftp url per session. Also tested and behaves correctly on: - Linux6 1999120608 - WinNT 1999120608 Re-opening bug.

Clearing WorksForMe resolution due to reopen.

This recent re-opening was really bug 20917 which I just fixed.

warren, when you say you just fixed it, does that mean it's a fix that we'll see in tomorrow's builds? Or is it something that was supposed to work in today's builds?

ok, Marking this verified because the original bug (as described in the comments, not the summary field) appears fixed. I will open a more specific report for what Chris is seeing. It does seem as though you can only access one ftp site per session on both mac and nt. 1999120908

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