251213 - ftp urls fail to load

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Asa Dotzler [:asa]]

In Windows build 20040712, FTP URLs fail to load. 

Steps to reproduce: 
1. Load ftp://ftp.mozilla.org (or any other ftp url)

Results:
No page is loaded. You're left at the page you had previously loaded. No errors
or allerts.

Expected: 
Load the ftp url and display ftp listing

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

2004071214 winxp... works here...

Comment 2

[Asa Dotzler [:asa]]

Christian, did you try with a new profile? I can't reproduce with my old (1.4
created) profile but I can reproduce with any new profiles I create. I also
tested with 2004071214 on XP.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Installer build or zip build?

Comment 4

[Asa Dotzler [:asa]]

Installer build.

Comment 5

[Darin Fisher]

WFM win2k mozilla-win32-installer.exe 20040713 trunk w/ existing profile and w/
new profile

i tested ftp://ftp.mozilla.org

Comment 6

[Darin Fisher]

Is anyone else able to reproduce this bug?  Asa, is it possible that one of the
ftp.mozilla.org mirrors was down when you tested?

marking WORKSFORME

if you can still reproduce this then please generate a FTP log file by setting
the following environment variables:
  
  NSPR_LOG_MODULES=nsFTPProtocol:5,nsSocketTransport:5
  NSPR_LOG_FILE=c:\log.txt

then launch mozilla, reproduce the bug, and attach log.txt to this bug report.
thanks!

Comment 7

[Asa Dotzler [:asa]]

Attachment: log for ftp failure

Launch mozilla, create new profile, browser loads start page, ftp.mozilla.org
entered into urlbar, failure, ftp.redhat.com entered into urlbar, failure.

Comment 8

[Asa Dotzler [:asa]]

I can reproduce this with any FTP urls I try to load. I can reproduce on a fresh
clean install and an over the top of a previos release install. I've tested with
several brand new profiles and can reproduce in all circumstances. 

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, seeing it on linux as well. debug build shows:
###!!! ASSERTION: Error: OnStartRequest() must be called before
OnDataAvailable(): '(eOnStart == mParserContext->mStreamListenerState ||
eOnDataAvail == mParserContext->mStreamListenerState)', file
/home/chb/mozilla/parser/htmlparser/src/nsParser.cpp, line 2389
Break: at file /home/chb/mozilla/parser/htmlparser/src/nsParser.cpp, line 2389
###!!! ASSERTION: How'd we get here with an unknown type?:
'!aParserContext.mMimeType.IsEmpty()', file
/home/chb/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 311
Break: at file /home/chb/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 311
###!!! ASSERTION: How'd we get here with an unknown type?:
'!aParserContext.mMimeType.IsEmpty()', file
/home/chb/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 985
Break: at file /home/chb/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 985
WARNING: NS_ENSURE_TRUE(mSink) failed, file
/home/chb/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 1005
Error loading URL ftp://ftp.redhat.com/ : 8000ffff (NS_ERROR_UNEXPECTED)

Comment 10

[Darin Fisher]

whoa... that's wierd.  i was just able to reproduce it too!  moments ago it
worked fine :-/  investigating....

Comment 11

[Darin Fisher]

Asa: have you narrowed down the regression window at all?  Did this just start
appearing with today's builds?

There weren't any changes to necko in the last week that could even remotely
explain this (bonsai query: http://tinyurl.com/4mxgm).

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

303         rv = mBundle->FormatStringFromName(NS_LITERAL_STRING("DirTitle").get(),

that fails, with NS_ERROR_UNEXPECTED (0x8000ffff), as seen in asa's log

307         if (NS_FAILED(rv)) return rv;

this returns that code from onstartr, which cancels the channel

this is all inside nsIndexedToHTML.cpp

Comment 13

[Darin Fisher]

i can repro w/ 20040712 and 20040713 seamonkey trunk on linux.  trying other
builds now.

Comment 14

[Darin Fisher]

i can repro the bug in 20040709 but not in 20040704 .. so that narrows the
regression window.  trying other builds now...

Comment 15

[Darin Fisher]

(In reply to comment #14)
> i can repro the bug in 20040709 but not in 20040704 .. so that narrows the
> regression window.  trying other builds now...

i take that back... the 20040704 build does not work either.  i made the mistake
of running mozilla 1.7 before testing the 20040704 build, and for some reason...
that changed the results.

Comment 16

[Felix Miata]

Mozilla.org Linux 2004070706 WFM.

Comment 17

[Darin Fisher]

bug definitely does not appear in the 20040621 trunk linux build.

felix: is that with a fresh profile?

Comment 18

[Darin Fisher]

OS -> All

Comment 19

[Darin Fisher]

OK, this regression started with the 6/29 trunk builds.  I cannot reproduce the
problem using the 6/28 trunk build.

Comment 20

[Darin Fisher]

This is a regression from bug 248847, which removed unused resource files.  I
must not have done something right when removing those files.  Investigating....

Comment 21

[Darin Fisher]

> This is a regression from bug 248847, which removed unused resource files.  I
> must not have done something right when removing those files.  Investigating....

This is _likely_ a regression from that bug.  I haven't confirmed it yet.  The
problem seems to be related to the fact that the chrome.rdf files stored in the
profile directory is smaller than it should be when generated by newer builds.

This is probably affecting more than just Necko.

Comment 22

[Martin Creutziger [:MMx]]

FYI: I can reproduce this bug on MacOS X 10.3.4 using "Mozilla/5.0 (Macintosh;
U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040713 Firefox/0.9.1+"

Comment 23

[Darin Fisher]

Attachment: v1 patch

OK, this patch solves the problem.  Thanks to bryner for explaining why this is
needed.

Comment 24

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 153067 [details] [diff] [review]
v1 patch

r=me, although I can't say I know this chrome registry stuff...

Comment 25

[Asa Dotzler [:asa]]

Comment on attachment 153067 [details] [diff] [review]
v1 patch

a=asa when this is reviewed.

Comment 26

[Darin Fisher]

fixed-on-trunk

Comment 27

[Brad Roberts]

Hey.. this fixes the 'brad' tinderbox orangeness that's been occurring for several weeks now.  Whee!  I'll 
move it back to the main tinderbox page.  I assumed it was a box specific problem since it started 
occurring coincidental with the box going very flakey (rebooting itself constantly).

Thanks!