86141 - file://<drive letter>:\dir\file no result

Status: RESOLVED WORKSFORME

(Core :: Networking: File, defect)

Description

[Martyr]

May be related to bug #70871, since the part of the link failing is probably the
same (initial server/drive letter).

Reproduced on Moz 0.9.1 milestone, Win NT (browser) Service pack 4, 256 Mb.

Selecting the type of link above launches the file successfully from a page
stored on NT. However, when the page is moved over to Win 2000, then Moz won't
launch the file from that link. NS 4.7.x (NT) and IE 5.x (NT) launch the file
just fine.

NT references the Win2000 area as a web folder, so perhaps there are some
translation woes there? If this bug is a variant of 70871, then at least this
expands it from server name lookup problems to shared-drives/mapping and to
another OS.

Comment 1

[Doug Turner (:dougt)]

try these combos:

file://<drive letter>|\dir\file
file://<drive letter>:/dir/file
file:///<drive letter>:\dir\file
file:///<drive letter>|\dir\file

Comment 2

[Martyr]

Same result for each of the variations. The status bar also displays all slashes
reversed from their appearance in the file, following the <drive letter><: or |>
for the entries with three initial slashes.  

Comment 3

[Martyr]

Fixing the OS affected (browser is running under NT SP 4). Anyone with a Win2k
share out there to help test? 

Comment 4

[Doug Turner (:dougt)]

Does:

file:///<drive letter>|/dir/file work for you??

Comment 5

[Martyr]

No, that fails to load the file also. I also swapped the spaces in the filename
for %20's  and got the same result. 
 

Comment 6

[Chad Austin]

I see this in win2k 2001061804

Comment 7

[benc]

I'm not incredibly familar with drive sharing, esp. the modern stuff.

Can you expand the summary so that it is descriptive of this aspect of the problem?

Comment 8

[benc]

What is the real path of the file you are trying to reference?

Comment 9

[Martyr]

Ok, I'll hit it this Mon or Tues (files and access to a 2k machine only at work). 

Comment 10

[benc]

+qawanted:

What would be ideal here is something like:

"On a certain version, these links fail in the location field, but work in some 
other OS"

Comment 11

[Gabriel Wilkins]

2001102808(0.9.5+) on winXP
file:/ and file:// seem to always be autochanged to file:///, which is good.
all "\" are autochanged to %5C,  : seems to be not changed, [guesswork] unless
there are no "/" in the url (all are "\"), in which 

case ":" becomes "%3A".[/guesswork]

There also seems to be a problem loading children if you are loading a frameset.
For instance,
file:///h:/javabook/frames.htm  WORKS
file:///h|/javabook/frames.htm  WORKS
but
file:///h|/javabook\frames.htm  FAILS
file:///h:/javabook\frames.htm  FAILS
these both fail with an alert saying "the file /SimpCont.htm cannot be found. 
please check the location and try again." 

(substitute actual frameset's child filenames in the alert, one per child.)
and this:
file:///h:\javabook\frames.htm FAILS differently,
with an alert, "the file /h%3A%5Cjavabook/frames.htm cannot be found.  Please
check the location and try again." 

Incidentally, none of these failures happen in 0.9.5.
0.9.5 i dont see any : -> %3a substitution, all \ are changed to / before the
page is loaded, and any combo i threw at it seemed to just work.

Comment 12

[benc]

Gabriel: Thanks for the detailed comments.

Let me try to address several points you raised...

DOS drive letters are often included as "c:" or "c|". My reading of RFC
1680+1738 is uncertain if these are legal, and I can't figure out where someone
decided ":" -> "|", but lets assume they are *both* legal for now.

"slash count correction" works for "file:" and "file:/" -> "file:///" This is no
bug that documents this, it seems to be a 4xp behavior as well.

> file:///h|/javabook\frames.htm  FAILS
> file:///h:/javabook\frames.htm  FAILS

Makes sense, although the error message text you provided was odd (is
"/SimpCont.htm" the original URL that loads the frames?

> file:///h:\javabook\frames.htm FAILS differently

It appears the DOS drive recognition code is pretty specific, probably expecting
only two letters between slash 3 & 4. Instead, your URL seems to take
"h:\javabook\frames.htm", as one "fsegement", and escape it.

re: works in 0.9.5. 
There have been some checkins to improve URL handling, so that might explain the
post milestone change. 

Comment 13

[Gabriel Wilkins]

now on build 2001102903.
to clarify the alert " can not find SimpCont.htm", SimpCont.htm is a frame 
defined in frames.htm.  this alert will popup for every frame defined in the 
file.  looking at this more is getting confusing, i'll look at it more later.

essentially, sometimes : -> %3A, and sometimes it doesnt.
Sometimes the page loads properly, sometimes it fails to find the frameset, and 
sometimes it loads the frameset but fails to load the frames.

Comment 14

[guivho]

On a Win2k build 2195 box with 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 
following url works from the bookmarks and when typed into the location field,
but not when clicked on a page: file:///C:/aww/SpacetimeWrinkles/index.html
This is obviously not a share as its pointing to a file on my C drive.

Same for file:///c|aww/SpacetimeWrinkles/index.html

Idem for c:\aww\SpacetimeWrinkles\index.html which turns into
file:///C:/aww/SpacetimeWrinkles/index.html

file:///aww/SpacetimeWrinkles/index.html does not work at all

Comment 15

[benc]

guido:

Is your the link-in-page example on a server (http:) ?

If so, that is checkloadURL stopping your link-click.

Comment 16

[s.marshall]

I am not sure if this is the same issue or if it is a different bug, but Mozilla
has problems running filenames (in Windows 98/2K/etc) when they are launched
from the operating system, if they contain a mixture of back and forward slashes.

For example, if you go to Start/Run and type:

c:\myprogram\data/help.html

(Better make it a file that exists...)

These can occur because forward slashes are perfectly legal path separators in
Windows; applications should treat them precisely identically when referring to
disk files. It is likely to happen when a software application uses ShellExecute
to launch an html file. The application requests the path data/help.html and
Windows appends the current directory c:\myprogram\, hence the mixed slashes.

It works correctly in IE, but fails in Mozilla with a 404 page about some
bizarre URL.

Comment 17

[benc]

Launching the application w/ a file reference is a specific entrypoint for a
file:/// URL, and we've had issues w/ specific aspects before.

Please make that a new bug.

Comment 18

[benc]

Reviewing this bug, I think this is WFM.

Based on the original URL here's what should happen:

The drive letter is in the hostname field, but that is fixed...
file://<drive letter> becomes file:///<drive letter>

Then we deal with the path, which has DOS slashes.

The DOS slashes seem to work fine in a file URL on a DOS system, which surprised
me because I think we have bugs about this not working via HTTP. They are
displayed in the URL bar as "%5C", which is discussed in bug 26578.

If someone could VERIFY if you agree, or REOPEN if this does not work for you.

Comment 19

[Andreas Otte]

There is no longer any code in the urlparser that converts \ to /, however there
is still some conversion code in the docshell, which usually only gets triggered
when entering the url through the location bar. I have seen instances where this
fixup code was also triggered when clicking on links, my guess when a page load
failure happens, but I did not look much further into this.

When parsing a file url from a link in a page I think it depends on the position
of the \'s. Depending on the positions of the \'s the url will be broken down
differently and when converting to a real filesystem path only parts of the url
will be used. That might explain the changes in behavior when changing \'s.

The code that converts from a file url to a filesystem path has been changed
some time ago, may be we are more forgiving now.

The | <-> : stuff is not part of any RFC I know, it is a 4xp thing. It was done
to prevent url parsers from interpreting c:\path\file as a url with protocol c.