[webkit-dev] Correct relative URL behavior

Brett Wilson brettw at chromium.org
Wed May 4 13:14:54 PDT 2011

On Wed, May 4, 2011 at 2:49 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On May 4, 2011, at 2:33 AM, Xianzhu Wang wrote:
> Hi,
> KURL's relative URL behavior is different between Chromium and non-Chromium
> ports, because Chromium ports use KURLGoogle.cpp instead of KURL.cpp.
> In KURL(base, relative), when base is a not hierarchical, WebKit's
> KURL::string() returns relative, while Chromium's returns an empty string.
> The behavior of Chromium
> causes https://bugs.webkit.org/show_bug.cgi?id=55643 (Chromium unnecessarily
> creates SVGImage when an SVG document contains images).
> I'm wondering which behavior is correct. Assuming WebKit's KURL behavior is
> correct, my first patch is to change KURLGoogle.cpp to match KURL.cpp, which
> affects the result
> of fast/url/relative.html. platform/chromium/fast/url/relative-expected.txt
> contains all PASSs, while fast/url/relative-expected.txt contains 8 expected
> FAILs, 2 of which relate to my question:
> I don't know if KURL's behavior is correct, but I believe Chromium's
> behavior of resolving to an empty string URL in this case is not matched by
> any other browser. So I am pretty sure KURLGoogle is incorrect.

I agree that the Google behavior should be changed when resolving
against a non-hierarchical base, although I think there are some cases
where I think KURL is also incorrect here (I don't remember
specifics). Adam is correct that there's a fair amount of ambiguity,
so it's difficult to declare either one correct for some cases.

> FAIL canonicalize('baz.html') should be . Was baz.html.
> FAIL canonicalize(':foo') should be . Was :foo.
> My questions are:
> 1. Are all the PASS expectations of fast/url/relative.html correct? If yes,
> we should file a bug to track the failures of KURL.
> 2. With my patch, Chromium will produce the above two FAILs for
> fast/url/relative.html. Is this acceptable to be rebaselined?
> Adam made the test expectations all have PASS matching google-url behavior,
> without analysis of what is actually correct. I think it may be misleading
> for the tests to say PASS/FAIL at all at this point, but I would say the
> test should be rebaselined.

Note that the fix would be in the google-url project rather than in
the KURLGoogle.cpp. The change will likely be several weeks of work.
This hasn't been fixed yet because we've not seen it affect real


More information about the webkit-dev mailing list