[webkit-dev] EWS Bots are Sick
App Engine went down this afternoon. The bots (commit-queue, sherriff-bot, ewses, etc.) haven't really recovered yet. Adam and I will work to bring them all back up tomorrow. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[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
[webkit-dev] Core bots build system
Hi, I want to add .h, .cpp and .idl files into WebCore platform independent parts. The questions are: - How many build systems are there for build bots? - For each type of build bots, where are the project files into which I should add .h, .cpp and .idl? (I know qt port) - Is there a wiki page or something to guide this scenario? (I think this scenario is common) - Is the unified build system in progress? Leo ___ 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