270202 - URIfixup should not be triggered for A links

Status: RESOLVED FIXED

(Core :: Networking: File, defect)

Description

[Jez]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

This is closely related to a previous bug I file, bug #190821.

Mozilla's URIfixup seems to kick in when an A link is created that uses '\' as a
directory delimiter instead of '/'.  This behaviour is incorrect.  The '\'
characters should be escaped to '%5C' as is the current behaviour - but the
resulting URI should then be evaluated correctly.

If there's a file called foo/mydir/file.htm and you link to it from foo using
the URI "mydir\file.htm", Mozilla inserts the path "(base
path)/mydir%5Cfile.htm" into the address bar.  So far so good.  However, this
URI (unless there really is a file called "mydir\file.htm" should result in a
'file not found' error, as it is not the same as "mydir/file.htm".  Instead,
Mozilla bizarrely loads the file as if the '\' delimiter had been a '/'.  This
behaviour is wrong, and needs fixing.

Reproducible: Always
Steps to Reproduce:
1. Create an A tag in an HTML page locally referencing a file using '\' as a
delimiter.
2. Click on the A tag.

Actual Results:  
The referenced page loads as if the '\' delimiters had been '/', and the '\'
delimiters are converted to '%5C'.  The images on the loaded page are all broken.


Expected Results:  
Displayed an error message along the lines of 'File not found.'

Comment 1

[Jez]

Attachment: Shows Mozilla not dealing with '\' in local A link correctly

Added a testcase attchment illustrating Mozilla's erroneous behaviour.

Comment 2

[Jez]

Changing OS to Windows XP, although I think this bug applies to all Windows OSes
and maybe Mac as well.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is almost certainly a duplicate (of the bug on the fact that we just pass
off the filepath to an nsIFile, which treats '\' as a dir separator).  The
URIFixup code is never involved here.

Comment 4

[Jez]

Boris,

I'm not sure what bug your above comment is referring to.  When you get back
could you please reply or e-mail me and tell me?

Comment 5

[Andreas Otte]

(In reply to comment #3)
> This is almost certainly a duplicate (of the bug on the fact that we just pass
> off the filepath to an nsIFile, which treats '\' as a dir separator).  The
> URIFixup code is never involved here.

Boris, which bug are you talking about? Can you give me a hint?

Comment 6

[Darin Fisher]

-> default owner

Comment 7

[Masatoshi Kimura [:emk]]

Fixed by bug 249282.