Closed Bug 59039 Opened 19 years ago Closed 19 years ago

FTP should proxy back nsIPrompt like HTTP


(Core Graveyard :: Embedding: ActiveX Wrapper, defect, P3)

Windows 98


(Not tracked)



(Reporter: geshp, Assigned: dougt)




From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
BuildID:    2000101014

When I typed in, 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:password@ftp.anyserver 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
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
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
nsThread::Main(void * 0x034bc5b0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x034bc440) line 399 + 13 bytes
_threadstartex(void * 0x034bc340) line 212 + 13 bytes
OS: Windows 98 → All
Summary: Can't view FTP sites while using ActiveX wrapper → Can't view FTP sites from embedding
The ftp connection thread should be doing something like the http channel does 
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
OS: Windows 3.1 → Windows 98
Reassigning to Doug
Assignee: adamlock → dougt
Blocks: 64833
Adjusting summary.  With the fix for 64795, I can view ftp in an embedding

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 → ---
Target Milestone: --- → Future
Target Milestone: Future → mozilla0.9.2
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.
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, please could you verify this is not failing anymore on recent 
mozilla builds. Thanks!
No longer blocks: 64833
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.