[webkit-dev] Correct relative URL behavior
Xianzhu Wang
phnixwxz at gmail.com
Wed May 4 18:08:45 PDT 2011
2011/5/5 Brett Wilson <brettw at chromium.org>
> 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
> sites.
>
>
The bug 55643 is an example of the effect. Though it doesn't have visual
effect, it'll
degrade performance when an SVG document containing images is loaded.
Brett
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110505/ad2c395b/attachment.html>
More information about the webkit-dev
mailing list