Test Case: Use Netscape 6 PR2 to go to ftp://ftp.netscape.com. Browser has no response. No error message and looks like not reading the FTP Url. But Netscape 4.73 is loading the same ftp site. This is tested on Aug 24th build for solaris on solaris 8 .

worksforme on win32 and Mac.

I have the same problem (with any ftp site) on current CVS on linux. I get the following assertions on the console: ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(DoURILoad(aURI, aReferrer, aOwner, loadCmd, aWindowTarget, aPostData))) failed: '(!((DoURILoad(aURI, aReferrer, aOwner, loadCmd, aWindowTarget, aPostData)) & 0x80000000))', file nsDocShell.cpp, line 2829 ###!!! Break: at file nsDocShell.cpp, line 2829 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(LoadURI(uri, 0))) failed: '(!((LoadURI(uri, 0)) & 0x80000000))', file nsDocShell.cpp, line 1358 ###!!! Break: at file nsDocShell.cpp, line 1358 This occurs when I type into the URL bar, or use File_OpenWebLocation, or click on an ftp link on a web page. I noticed this last night (GMT+10/11 - about 18 hours ago, +/- 1 or 2), but I put it down to the fact that my uni proxies were a bit flacky. Its still happening now though.

Changing to PC/Linux as this is reproducable there. Increasing priority to P1 as this is important functionality.

this worksforme with 0831 linux build.

Reoping bug, and resetting to Sun/Solaris where this is still a problem with a tip-of-the-tree build I pulled this afternoon. Last console messages displayed when attempted to go to location: ftp://ftp.netscape.com were: nsWidget::~nsWidget() of toplevel: 8 widgets still exist. ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(DoURILoad(aURI, aReferrer, aOwner, aInheritOwner, loadCmd, aWindowTarget, aPostData))) failed: '(!((DoURILoad(aURI, aReferrer, aOwner, aInheritOwner, loadCmd, aWindowTarget, aPostData)) & 0x80000000))', file nsDocShell.cpp, line 2812 ###!!! Break: at file nsDocShell.cpp, line 2812 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(LoadURI(uri, 0))) failed: '(!((LoadURI(uri, 0)) & 0x80000000))', file nsDocShell.cpp, line 1350 ###!!! Break: at file nsDocShell.cpp, line 1350

I did some more testing, and it appears that this only occurs when using proxies. If I turn of the proxy settings, and then restart mozilla, I can connect to locations inside the firewall with ftp. I have to restart - I get the same assertion otherwise. I'm using manual proxies, with usyd.edu.au excluded, but it doesn't work unless I select "Direct connection to the internet", even to sites inside usyd.edu.au. Are the other people who are seeing this using ftp proxies? Changing componant to networking.

Use of a proxy would confirm my findings too. We use a proxy here at Sun; it failed. cls tried it last night on a Linux build with a direct connection and it was successful. This is a major problem. I'm currently working with the folks on IRC #mozilla to see if we can replicate this problem with a proxy on other platforms.

Changing to All/All. This fails for other folks here at Sun, on Windows NT and Linux (both through a proxy). Adding nsbeta3 keyboard.

reassigning

with linux 2000080121 and 2000090206 i can' connect to ftp sites, and i'm not using a proxy. Seems loading never even starts - an indication being that i can still scroll in the currenly loaded web-page. (Scrolling normally dies the moment another url starts loading somewhere in background)

Do you get an assertion on the console? Do you have proxys enabled in prefs (ie set to manual proxies, even if you have nothing in any of the fields)? I still see this with a ~12 hour old build.

No assertions, just "failed to load" when i finally click stop. And what's more: it never times out. It's as if the request to load the url never goes anywhere.

*** Bug 51205 has been marked as a duplicate of this bug. ***

For the ftp + proxy problem see main bug 33122: "Can't download FTP file through proxy"

With 2000-090321 M18 linux i can suddenly load ftp sites again. No settings here are changed. (And as to the question about proxy settings: no, i never use them and they are and were not set to manual)

oh well.. it loaded once. Next time i started moz (same ID) it didn't work again.

Adding dependancy on bug# 33122

*** Bug 51438 has been marked as a duplicate of this bug. ***

->rjc

*** This bug has been marked as a duplicate of 33122 ***

Verified dupe of just fixed bug 33122: "Can't download FTP file through proxy"