149247 - When launching a file, mixed slashes (forward and back / \ ) cause problems

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Cmd-line Features, defect)

Description

[s.marshall]

Mozilla (1.0 RC3) has problems running filenames in Windows 98 when they are
launched via the operating system, if they contain a mixture of back and 
forward slashes.

To reproduce:

1. Create a file c:\temp\test.html
2. Click Windows Start, Run
3. Type c:\temp/test.html

Expected result:

Mozilla launches with the file given.

Actual result:

On Windows 98, Mozilla launches and gives an error after trying to find the file
on a network path, www.c.com.

On Windows 2000, Mozilla works correctly. (You can see the same behaviour on
both platforms if you actually type a filename with mixed slashes into the
location bar, which might or might not be acceptable behaviour anyway.)


These can occur because forward slashes are perfectly legal path separators in
Windows; applications should treat them precisely identically when called by the
operating system to open a disk file. The only real likelihood of this happening
is when a software application uses ShellExecute to launch an html file. The
application might request the path data/help.html and Windows (98) appends the
current directory c:\myprogram\, hence the mixed slashes
c:\myprogram\data/help.html.

(Reporting as separate bug, as requested in bug 86141.)

Comment 1

[benc]

When a file path is coming through product launch, I think this goes to URL
bar... but not entirely sure. 

Doug, any suggestions where this goes? Otherwise I'll send it to browser-general
and let them route it. 

Comment 2

[Jouni Heikniemi]

*** Bug 156411 has been marked as a duplicate of this bug. ***

Comment 3

[benc]

Isn't the options on launch part of XP-apps?

Comment 4

[benc]

(dupe was invalid)

-> XP-apps to see what they think.

Comment 5

[nemo]

Further problem, using Win2k and Mozilla.
Have a URL of form:
file:///path\to\in\depth/help/index.html

Mozilla parses the URL correctly, but then fails to display portions of the page
which are relative such as:
<img src="../../../../images/example.gif">
I suspect Mozilla is unable to tell that  ../../../../ is equivalent to
..\..\../../ .

Interesting, this otherwise miserable product supposedly had a help system
compatible with NS4.x - perhaps this is a regression.

Personally, I think Mozilla should follow IE's lead.
it converts:
file:///path\to\in\depth/help/index.html
to:
file:///path/to/in/depth/help/index.html  
when parsing the document, and for all relative links.  Easy to do, small
operating system dependent URL preprocessing.

Comment 6

[nemo]

Simpler test.
If you manually enter 
	file:///C:%5CWINNT 
into URL bar, it will load.  However,
	file:///C:%5CWINNT/.. 
will not send you back to C:\
	file:///C:/WINNT/.. 
does.

Comment 7

[Ronak]

I'm using FireFox 1.0 on Windows XP. The bug seems similar to the description
mentioned below, but I noticed some more pecularities in it.

For the following HTML Code:
<p align=center style='text-align:center'><span style='font-family:"Trebuchet
MS"'><a href="EastTrip\DC.html">Washington DC</a><o:p></o:p></span></p>
and 
<p align=center style='text-align:center'><span style='font-family:"Trebuchet
MS"'><a href="EastTrip/phili.html">Philadelphia</a>

The second link is resolved correctly and I can view the link, but in the first
link I get a page not found as the link does not get resolved. The same two
links work just fine in IE, which is able to resolve it even before the link is
clicked (i.e. onMouseOver event, I can see the link is fine in IE but not so in
FireFox)

Another bigger issue here seems that I was able to view the Page source in IE
for that frame which contained these links, but I was not able to view the Page
Source in FireFox.