[webkit-dev] Correct relative URL behavior
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:
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?
Thanks,
Xianzhu
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Correct relative URL behavior
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Correct relative URL behavior
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.
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.
Yeah, I wish I could make script tests that didn't output PASS/FAIL
because it's unclear how URL parsing in browsers should behave (which
is something we're trying to fix in standards-land).
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Correct relative URL behavior
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
Re: [webkit-dev] Correct relative URL behavior
On May 4, 2011, at 2:42 PM, Adam Barth wrote: I wish I could make script tests that didn't output PASS/FAIL What's stopping you? -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Correct relative URL behavior
On Wed, May 4, 2011 at 1:23 PM, Adam Roben aro...@apple.com wrote: On May 4, 2011, at 2:42 PM, Adam Barth wrote: I wish I could make script tests that didn't output PASS/FAIL What's stopping you? Probably ignorance. How do I do it? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Correct relative URL behavior
2011/5/5 Brett Wilson bre...@chromium.org
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.
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Correct relative URL behavior
On May 4, 2011, at 1:59 PM, Adam Barth wrote: On Wed, May 4, 2011 at 1:23 PM, Adam Roben aro...@apple.com wrote: On May 4, 2011, at 2:42 PM, Adam Barth wrote: I wish I could make script tests that didn't output PASS/FAIL What's stopping you? Probably ignorance. How do I do it? You could use purely debug() macros instead of shouldBe() to log the results. Then the test would merely dump the values instead of comparing to expected values. The only expectations would be in the -expected.txt file. I do think the tests should be PASS/FAIL in the long run, once there is a spec to define the expectations. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
