21283 - [DOGFOOD]Only one FTP/File site per session

Status: VERIFIED DUPLICATE of bug 20691

(Core :: Networking, defect, P3)

Description

[Henrik Gemal]

It's only possible to see one FTP/File site per Mozilla startup.

There seems to be a redrawing problem, so that I have to restart Mozilla almost
everytime after hitting one ftp:// site or file:// location.

I start Mozilla and www.mozilla.org shows fine. Now I go to ftp.netscape.com and
it shows fine. Now I want to go to ftp.dk.net and I'm getting a screen that just
contains all my other Win32 programs.
The DOS prompt states:
 FindShortcut: in='ftp://ftp.dk.net/'  out='null'
 Document ftp://ftp.dk.net/ loaded successfully
 Document: Done (3.9 secs)

If I go to www.mozilla.org it show ok, but i cant show any FTP/File sites!

I just seems like the screen doesn't get redrawn...

Damn annoying that I can only test ONE ftp site without having to restart
Mozilla.....

Comment 1

[Scott MacGregor]

I think the problem may be related to the chrome cache stuff that waterson was
working on as part of brutal sharing.

I visited the first ftp site and everything was fine. When I visited a second
one, I asserted with the following stack trace:
nsDebug::Assertion(const char * 0x01fe5d8c, const char * 0x01fe5d6c, const char
* 0x01fe5d3c, int 4858) line 186 + 13 bytes
nsXULDocument::ExecuteScript(JSObject * 0x02c4ea70) line 4858 + 49 bytes
nsXULDocument::LoadScript(nsXULPrototypeScript * 0x0392a9f0, int * 0x0012f998)
line 4745 + 15 bytes
nsXULDocument::ResumeWalk() line 4557 + 19 bytes
nsXULDocument::CachedChromeStreamListener::OnStopRequest(nsXULDocument::CachedChromeStreamListener
* const 0x047de4b0, nsIChannel * 0x049286b0, nsISupports * 0x00000000, unsigned
int 0, const unsigned short * 0x00000000) line 5603
nsCachedChromeChannel::AsyncRead(nsCachedChromeChannel * const 0x049286b0,
unsigned int 0, int -1, nsISupports * 0x00000000, nsIStreamListener *
0x047de4b0) line 159
nsDirectoryViewerFactory::CreateInstance(nsDirectoryViewerFactory * const
0x04950990, const char * 0x04950740, nsIChannel * 0x04952ca0, nsILoadGroup *
0x047ca7d0, const char * 0x04952c00, nsISupports * 0x047cacf0, nsISupports *
0x00000000, nsIStreamListener * * 0x04950794, nsIContentViewer * * 0x0012fd28)
line 1053 + 38 bytes
nsDocLoaderImpl::CreateContentViewer(const char *
0x04950740, nsIChannel * 0x04952ca0, const char * 0x04952c00, nsISupports *
0x047cacf0, nsISupports * 0x00000000, nsIStreamListener * * 0x04950794,
nsIContentViewer * * 0x0012fd28) line 470 + 55 bytes
nsDocumentBindInfo::OnStartRequest(nsDocumentBindInfo * const 0x04950780,
nsIChannel * 0x04952ca0, nsISupports * 0x00000000) line 1370 + 81 bytes

The chrome url the directory viewer is trying to load is:
chrome://directory/content/

After the assertion about not having a script context, we fail to load the page.
Visiting any other ftp site that involves loading this url gives me the same result.

Comment 2

[Judson Valeski]

I'm getting the same stack and assertion.

Comment 3

[rickg]

Putting on radar

Comment 4

[Scott MacGregor]

I belive waterson fixed this problem for us with his fixes for another bug. I'm
now at home. I'll try it out tomorrow and mark this as fixed if it does indeedd
do the trick! Thanks Chris!

Comment 5

[Scott MacGregor]

waterson's fix for Bug #20691.

Marking this a a dup. I've verified that his patch for that bug fixes the ftp
problem.


*** This bug has been marked as a duplicate of 20691 ***

Comment 6

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 7

[varada]

able to go to multiple ftp sites
marking verified - windows build - 1999121508