Closed Bug 59039 Opened 19 years ago Closed 19 years ago
FTP should proxy back ns
IPrompt like HTTP
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) BuildID: 2000101014 When I typed in ftp://username:email@example.com, it said there were no files in it. Reproducible: Always Steps to Reproduce: 1. Create a mozillabrowser control in VB6 2. Type in ftp://username:firstname.lastname@example.org as the url Actual Results: No files were listed Expected Results: Should have listed all the files in the directory
I tested this and I didn't see this problem. I went to my ftp server on my ISP and it listed the contents of my web page. AMD K6-2 350MHz, 64M RAM OS: WinME Mozilla Build 2000110304
oops, forgot this: useragent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18)
It looks like the control and probably other embedding clients is running foul of the content (rdf?) viewer used for ftp sites. Assigning to me.
Assignee: locka → adamlock
Status: UNCONFIRMED → NEW
Ever confirmed: true
Changing title of the bug. One of the problems I encounter trying to debug this is that the ftp thread is trying to refcount a pointer to the nsIPrompt object. This is implemented on another thread by the control's CWebBrowserContainer object. In Debug mode this throws up a whole bunch of assertions because the object is not threadsafe etc. Stack trace is below. If it's possible the ftp thread should be using a marshalled nsIPrompt pointer. CC'ing Jud for opinions. NTDLL! 77f7629c() nsDebug::Assertion(const char * 0x10065c48, const char * 0x012ba54c, const char * 0x012ba520, int 0x000001e8) line 254 + 13 bytes NS_CheckThreadSafe(void * 0x00304910, const char * 0x10065c48) line 488 + 34 bytes CWebBrowserContainer::AddRef(CWebBrowserContainer * const 0x034ba2a0) line 51 + 55 bytes nsCOMPtr_base::assign_with_AddRef(nsISupports * 0x034ba2c0) line 58 nsCOMPtr<nsISupports>::operator=(nsISupports * 0x034ba2c0) line 763 nsFTPReleaseEvent::nsFTPReleaseEvent(nsISupports * 0x034ba2c0) line 97 nsFtpConnectionThread::Run(nsFtpConnectionThread * const 0x015e5918) line 1635 + 42 bytes nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x034bc600) line 720 + 12 bytes nsThread::Main(void * 0x034bc5b0) line 84 + 26 bytes _PR_NativeRunThread(void * 0x034bc440) line 399 + 13 bytes _threadstartex(void * 0x034bc340) line 212 + 13 bytes KE
The ftp connection thread should be doing something like the http channel does perhaps: http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHTTPChannel. cpp#663
FTP already proxies the nsIPrompt is uses. Must be some other object.
Are you sure about that? The nsHTTPChannel::SetNotificationCallbacks implementation creates proxy interfaces by calling nsHTTPChannel::BuildNotificationProxies and uses them when it has to. The nsFTPChannel::SetNotificationCallbacks, just passes the un-proxied callback interfaces straight into the thread initialization code.
Provisionally marking 0.9, but I feel there are a lot more issues with FTP and embedding than just being able to view the site.
OS: All → Windows 3.1
Target Milestone: --- → mozilla0.9
Reassigning to Doug
Assignee: adamlock → dougt
Adjusting summary. With the fix for 64795, I can view ftp in an embedding application. Removing milestone. This will be fixed after 0.9 unless someone has a tested patch.
Summary: Can't view FTP sites from embedding → FTP should proxy back nsIPrompt like HTTP
Target Milestone: mozilla0.9 → ---
mass moving target milestone. if there is time, i will try to pull things back in. email me if you think that this must be fixed for 0.9.2, preferably with a patch. :-)
Target Milestone: mozilla0.9.2 → mozilla0.9.3
I checked in fixes for this bug this afternoon. QA, please verify.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
I'm no longer working for Netscape as of 8/3/01, and haven't worked on Mozilla since late 1999. I'm not sure who should QA this, so I'll reassign to gerardok.
QA Contact: cpratt → gerardok
email@example.com, please could you verify this is not failing anymore on recent mozilla builds. Thanks!
You need to log in before you can comment on or make changes to this bug.