User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 When you enter this URL in IE: file:///C:%5CProgram%20Files%5CMacromedia%5CFlash%20MX%5CUntitled-1.html You get this: C:\Program Files\Macromedia\Flash MX\Untitled-1.html Mozilla does not convert this type of URL, and subsequently, does not browse to the correct location. Reproducible: Always Steps to Reproduce: 1. Point IE to "file:///c:%5C". Notice it converts "%5C" to "\" 2. Point Mozilla to "file:///c:%5C". Mozilla does not convert the URL. Actual Results: The page could not be found Expected Results: Mozilla converts "file:///c:%5C" to "file:///c:\" When you publish a preview in flash MX, flash puts these "%5C" into the URL which causes the preview only to work in Internet Exploiter. If Mozilla also parses the URL, then there will be one less reason to keep IE around.
14 years ago
Assignee: general → darin
Component: Browser-General → Networking
QA Contact: general → benc
file:///c:%5C shows the drive C: for me, so does file:///c:\ so everything is correct. And there is no need to convert something in file:///c:%5C, since the \ needs to be escaped and that was already done here (\ is a so-called unsafe character). Tested with current CVS trunk build on win2k.
the problem is of course that the base uri will be wrong, so relative links in the page won't work
The patch in bug 249282 makes '\' work in Mozilla on Win32 and OS/2, but I don't think it will solve this problem.
Status: UNCONFIRMED → NEW
Depends on: 249282
Ever confirmed: true
As comment 1 it WFM. file:///c:%5c shows "Index of file:///c:\" as page and the URL remains file:///c:%5c which is correct behavior. So the page can be found. (In reply to comment #2) > the problem is of course that the base uri will be wrong, so relative links in > the page won't work Could you explain this on an example? I guess you mean something like in Bug 236440 because "\" is not treated as a path separator for URLs.
(In reply to comment #4) > Could you explain this on an example? I guess you mean something like in Bug > 236440 because "\" is not treated as a path separator for URLs. yes.
Summary: Mozilla does not convert "%5C" in a URL to "\" → URLs do not convert "%5C" to "\"
Confirmed on Firefox PR1. \ in links are treated directly at %5C, instead of /. This breaks files with URLs containing the unfortunate \ instead of /. If there aren't any other compatibility issues as a result, it would be best to treat / and \ the same.
Is there a patch available to convert \ to / in mozilla firefox.If yes can i get the steps to install it.?
valentin, what do you think the status of this bug should be?
Tehnically, it still applies, but I think we should WONTFIX it. comment 0 is a bit confusing but it seems the problem is that file:///C:/Program%20Files%5CTest/../ is resolved to file:///C:/ instead of file:///C:/Program%20Files The parser does translate regular \ to /. When opening the file for the given file URI, it unescapes the path, so we get the correct folder but %5C doesn't get replaced with /. We could do it, but I wouldn't encourage this kind of special casing. I have to note that Chrome has the same behaviour as Firefox (while edge and IE open a window to that path, so I can't really check). So does this URL parser implementation: http://intertwingly.net/projects/pegurl/liveview3.html The URL spec doesn't indicate that we should convert %5C to \ when parsing the URL, so I think WONTFIX would be appropriate.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.