Given a URL string like this:
KURL will parse it into:
Note that the colon has disappeared. During parsing, KURL treats the colon as introducing a port number, then sees no port and just ignores it.
A URL string like "file://localhost/c:\foo\bar" will be parsed correctly into "file://c:/foo/bar", however.
Is this a regression, and is it normally observable?
I don't think it's a regression.
It is observable in APIs like WKURLCreateWithUTF8CString correctly for Windows-style paths. See the workaround added in bug 55674, e.g.
I haven't tested whether it's a regression, though.
(In reply to comment #2)
> It is observable in APIs like WKURLCreateWithUTF8CString correctly for Windows-style paths.
I meant: it is obvservable in APIs like WKURLCreateWithUTF8CString, which are thus made hard to use correctly for Windows-style file: URLs.
If it's a regression, then see also: bug 54090.
I don't think this is a regression. file: urls are complicated, I've not done any work on them yet. :) See related results in:
This result seems particularly relevant:
FAIL canonicalize('//c:/foo') should be file:///C:/foo. Was file://c/foo.
File URLs are tricky. Most browsers parse them differently depending on whether they're running on Windows. Also, the three-slash versus two-slash question is pretty inconsistent.
In any case, eating the ":" is definitely wrong.
Chrome has extensive Windows-only filename parsing rules that closely match IE's behavior.
For some examples, see our unit tests:
(search for "CanonicalizeFileURL" and you can see there is a big Windows-only block).
(In reply to comment #9)
> Chrome has extensive Windows-only filename parsing rules that closely match IE's behavior.
We're also running those tests as LayoutTests:
URLParsing is now done according to spec.
*** This bug has been marked as a duplicate of bug 162660 ***