I tried to go to the ftp page listed above. This works in 4.x, but in mozilla produces: <body></body> in the window.
updating summary field. the "devworld" dir is actually a symbolic link.
hmmm. what build are you using? This is working for me (fresh tree pull as of mid afternoon today). Now my summary is missleading too. FTP doesnt' actually care if a "dir" is a sym link (though the dir listing shoudl note it).
I didn't say anything about symbolic links, you did. Changing the summary back to my original title.
I just tried this w/ the win32 11/23/99 nightly build and am not able to reproduce it. I can navigate the sym link, and goto the said url directly.
I just tried this again on my home machine, and was able to load the page listed in the url field above (the build is a few days older though). Then I tried going to ftp://ftp.apple.com and got a directory listing. I clicked on a bunch of the triangles and several of them opened to reveal subfolders, but then the app deadlocked. There seemed to be many threads blocked in the proxy code (sorry, but I didn't get a backtrace). I tried to reproduce it and couldn't. Sounds like there's some sort of race condition going on.
*** This bug has been marked as a duplicate of 20011 ***
I really think these bugs are unrelated. This one is a deadlock problem in the protocol. 20011 is a UI problem.
then lets update the summary to something a little more representative of the problem. I removed the dogfood status as I dont' think we need to be able to open multiple FTP dirs simultaneously. Note: I am unable to reproduce on build from this morning windows NT.
correction to previous posting. I do think we need to be able open multiple FTP dirs simultaneously, just not for dogfood.
The all-too-easy-to-trigger lockup does not, in current builds, lock the app entirely - the location bar and [Back] button still work, and if an http: URL or file: URL is loaded, the browser works normally until another ftp: URL is loaded, at which time it appears to lock up again. Tested with: 1999-12-09-08-M12 nightly binary on Windows NT 4.0sp3 Additional Information: Trying the equivalent with a tree resulting from a file: URL results in Bug 12749 "Unknown File Type error opening multiple file: directories" instead of a lockup.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
tever can you try to repro this on all three platforms? It should be fixed now.
marking fixed per engineers comments verified working on NT4.0, Mac OS8.6, Linux 6.0 all builds 2000011008
verified working on NT4.0, Mac OS8.6, Linux 6.0 all builds 2000011008
-> ftp + testcase