15200 - [BLOCKER] file url with no network access doesn't load

Status: CLOSED WONTFIX

(Core :: Networking, defect, P3)

Description

[karnaze (gone)]

The page never loads and the throbber keeps going. The page has no http
images. I even removed the http anchors and it made no difference. So, there is
no network access. This is a table regression test. This was not a problem on
9/22.

Comment 1

[Andreas Otte]

It works for me if I use the full path with / instead of \ (under linux) and the
file scheme. If it is simply used as stated above mozilla trys to make a http
connect to the host mozilla with layout ... as path or something like that. Is
this supposed to work?

Comment 2

[karnaze (gone)]

Sorry for the confusion. The page was loaded as:
file:///s:/mozilla/layout/html/tests/table/bugs/bug10633.html

Comment 3

[Warren Harris]

Rick, This is the "add timeouts to socket transport" bug that we discussed
today. I don't see a bug report for it off hand.

Comment 4

[rpotts (gone)]

I'm marking this bug as depending on bug #7428 which is the socket timeout
bug...  It sounds like something else is going on here too...

We shouldn't be making any socket connections to load a local page !!

Comment 5

[rpotts (gone)]

hey warren,
I can't figure out what the nsFilePath is doing to file:// URLs :-(  This is
what seems to be going on...

1. /mozilla/layout/html/tests/table/bugs/bug10633.html is passed into
   the nsFilePath constructor.
2. nsFileSpecHelpers::UnixToNative(...) is called and *removes* the initial '/'
   and converts all slashes...
3. nsFileSpecHelpers::Cannonify(...) is called.  However, the path is now
   mozilla\layout\html\tests\table\bugs\bug10633.html so it assumes it is a
   relative path and prepends S:\DIST\WIN32_D.OBJ\BIN to the path :-(
4. Now things are *really* messed up!

How did this ever work?  I'm giving you the bug, since I know nothing about this
nsFileSpec stuff...

Comment 6

[Warren Harris]

Sounds like part of dougt's nsIFile stuff.

Comment 7

[Daniel Veditz [:dveditz]]

Doug isn't going to get to this in M12. nsIFile may or may not have this
problem, but no one's going to touch nsFileSpec.

Comment 8

[leger]

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

component.

Comment 9

[Doug Turner (:dougt)]

will be fix by bug 22047.

Comment 10

[Doug Turner (:dougt)]

this was a nsFileURL problem.  Since necko will now use nsILocalFile to do
this, I am going to mark as WONTFIX,.

Comment 11

[Tom Everingham]

closing per comments