Closed Bug 59039 Opened 19 years ago Closed 19 years ago

FTP should proxy back nsIPrompt like HTTP

Categories

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

x86
Windows 98
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.3

People

(Reporter: geshp, Assigned: dougt)

References

()

Details

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

When I typed in ftp://username:password@home.midsouth.rr.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: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
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
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 
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
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
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 → ---
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.
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
geshp@netzero.com, 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.