Closed
Bug 59039
Opened 25 years ago
Closed 24 years ago
FTP should proxy back nsIPrompt like HTTP
Categories
(Core Graveyard :: Embedding: ActiveX Wrapper, defect, P3)
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
Comment 1•25 years ago
|
||
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
Comment 2•25 years ago
|
||
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
URL: (any) → ftp://ftp.mozilla.org
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
Comment 6•25 years ago
|
||
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
Updated•25 years ago
|
OS: Windows 3.1 → Windows 98
Assignee | ||
Comment 10•24 years ago
|
||
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 → ---
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → Future
Assignee | ||
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9.2
Assignee | ||
Comment 11•24 years ago
|
||
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
Assignee | ||
Comment 12•24 years ago
|
||
I checked in fixes for this bug this afternoon. QA, please verify.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
geshp@netzero.com, please could you verify this is not failing anymore on recent
mozilla builds. Thanks!
Updated•13 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•