Summary: | KURL parses Windows-style absolute file: URLs incorrectly | ||
---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | abarth, achristensen, ap, brettw, darin, eric |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | Windows XP |
Description
Adam Roben (:aroben)
2011-03-03 09:27:21 PST
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: http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/file-expected.txt http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/relative-win-expected.txt 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: http://code.google.com/p/google-url/source/browse/trunk/src/url_canon_unittest.cc (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: http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/script-tests/file.js http://trac.webkit.org/browser/trunk/LayoutTests/fast/url/file-expected.txt URLParsing is now done according to spec. https://bugs.webkit.org/show_bug.cgi?id=162660 *** This bug has been marked as a duplicate of bug 162660 *** |