On Wed, May 4, 2011 at 2:49 AM, Maciej Stachowiak <m...@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
sites.
Brett
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
