26578 - location field not un-escaping "\" in paths

Status: VERIFIED FIXED

(Core :: Networking: File, defect, P3)

Description

[Judson Valeski]

The said url produces file:///C%3A/ after it's loaded. We need to be un-escaping 
url bar text before we display it.

Comment 1

[Andreas Otte]

In general I have to disagree, but you are right in this case. What should
happen here is that the : is moved to |, try the attached patch.

Comment 2

[Andreas Otte]

Attachment: Patch to move : to | for XP_PC

Comment 3

[cbegle]

Hey, Jud.  Is there a reason why you use browser-general rather than the 
component that this affects?  This is kind of a catch-all component, kind of a 
staging area for stuff when people don't know where to put things.

See the components page:
http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
A "catch all" component for problems found when using the Browser which
do not fall into one of the current components. Example: launch/exit
crashes, features missing, etc. PLEASE NOTE!! Try to find a component
which is specific to your bug first - BEFORE assigning to this component!

Comment 4

[Andreas Otte]

Setting network component

Comment 5

[Judson Valeski]

when I filed this I didn't know where it should be fixed.

Comment 6

[Andreas Otte]

Jud, do you also want to review the attached patch?

Comment 7

[Judson Valeski]

andreas, I've been running with your patch for awhile with no adverse affects. 
Sorry I haven't communicated that. You want to check it in (r=valeski)

Comment 8

[Andreas Otte]

This should be fixed now even without the patch

Comment 9

[Andreas Otte]

This one is definitly fixed.

Comment 10

[benc]

This hangs in Win 98, after displaying the URL as unescaped.
That is bug is bug 165799.

Andreas: what should happen here? Should necko escape the inputed URL first, or
should URIfixup convert the string to a file URL that works? 

Comment 11

[benc]

VERIFIED: Windows 2K, Mozilla 1.4a
I'm going to mark this fixed, because andreas said so.

There have been enough changes where this doesn't work again.

Clicking on the link:
file://c:\ -> fails, no response.
file://c: -> file:///c:/

The general design assumptions of my testcases would say that the first example
is invalid anyhow, because the "hostname" field (between slash 2 & 3) is "c:\",
which is an invalid hostname.

For Windows only, we have a feature which I call "drive letter promotion", which
takes many combinations of DOS-style volumes (like "c:" and "c|" and moves it
one field to the left, before doing the file system access (hence the second
example working).

We keep making changes to "\" handling, but the current handling, as I
understand it is that URL parsing does not give it special treatment, but URL
bar, in Windows only does do "\" -> "/" mapping, on the assumption that people
might be cutting and pasting DOS paths from explorer or other DOS interfaces.

Using URL bar, not normal URL interfaces, you see the following:

type:file://c:\ ->URL bar: file:///c:%5C -> load file:///c:\.

In regards to location bar and unescaping, that doesn't seem to happen anymore.

file:///c:%5C or file:///c:\ as links both become file:///c:%5C in the URL bar.

This makes sense to me, because it is the correct URL, and people who cut and
paste would risk transfering broken URLs to other URL interfaces (some not our
own), if this did not happen. There is a contrasting general design idea, which
says that user-displayed stuff (like status bar and "Index of <URL>") should
show you the URL. Users can see this, so it is human readable, but not copy it
in that form.

Judson: there is no clear design document on what combinations should work.
There are many strange hybrid half file URL, half DOS path combinations, and we
do make a lot of them work. I don't test for this combination, but if you want
me to, we can discuss that offline or in another bug that deals w/ the current
behavior.

If you think this is wrong, a bug in URL bar is probably needed, and this could
be hashed out in more detail over there.

Comment 12

[benc]

Attachment: examples