[webkit-dev] Correct relative URL behavior

[Maciej Stachowiak]

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.

> 
> 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.

Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110504/d4c2252c/attachment.html>