[webkit-dev] test runtimes treemap
You can now see the test runtimes in treemap form for the lastest run of some of the layout test bots*. http://test-results.appspot.com/dashboards/treemap.html#testType=LayoutTests Also, the URLs are permalinked, so you can link to an individual subtree. At the lowest level, for layout tests, it shows you the actual test. For example, we can all wonder why LayoutTests/http/tests/xmlhttprequest/supported-xml-content-types.html takes 7 seconds: http://test-results.appspot.com/dashboards/treemap.html#treemapfocus=LayoutTests%2Fhttp%2Ftests%2Fxmlhttprequest%2Fsupported-xml-content-types.html(seems like this test could be really fast if it just used async XHR). Or why the http tests take 488 seconds: http://test-results.appspot.com/dashboards/treemap.html#treemapfocus=LayoutTests%2Fhttp Thanks to Evan for writing the treemap code. Ojan * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New tool: Leaks Viewer
Hi all- Over the last two weeks I've been working on a new tool for viewing leaks output from the SnowLeopard Intel Leaks bot. You can see it here: http://build.webkit.org/LeaksViewer/ (screenshot below). It uses the Inspector's Profiles panel code to present leak stacks in an outline view. I've found it pretty useful for finding leaks in our code. Please give it a whirl, and maybe plug some leaks! There are a number of known issues (particularly with the Heavy view), which can be found in Bugzilla by searching for "leaks viewer". If you file any new bugs please include that string in the title and CC me. I hope you find it useful! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] test runtimes treemap
On Thu, Mar 17, 2011 at 11:50 PM, Ojan Vafai o...@chromium.org wrote: You can now see the test runtimes in treemap form for the lastest run of some of the layout test bots*. http://test-results.appspot.com/dashboards/treemap.html#testType=LayoutTests Also, the URLs are permalinked, so you can link to an individual subtree. At the lowest level, for layout tests, it shows you the actual test. For example, we can all wonder why LayoutTests/http/tests/xmlhttprequest/supported-xml-content-types.html takes 7 seconds: http://test-results.appspot.com/dashboards/treemap.html#treemapfocus=LayoutTests%2Fhttp%2Ftests%2Fxmlhttprequest%2Fsupported-xml-content-types.html (seems like this test could be really fast if it just used async XHR). Or why the http tests take 488 seconds: http://test-results.appspot.com/dashboards/treemap.html#treemapfocus=LayoutTests%2Fhttp Thanks to Evan for writing the treemap code. Ojan * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. That is super cool. Thanks for putting this together. Could you put a permanent link to the treemap somewhere, maybe on the WebKit wiki? /goes off to figure out why the WebGL read-pixels-test.html is taking 7 seconds... -Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] A question about new-run-webkit-tests
On 2011-03-17, at 23:50, Ojan Vafai wrote: * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. Can someone explain the new-run-webkit-tests situation to me? The name suggests it is intended to replace run-webkit-tests. It's been more than a year since it was added and it obviously hasn't replaced run-webkit-tests. As best as I can tell it's not used by any ports unless one happens to invoke it directly. It appears to has new functionality that run-webkit-tests lacks, but on the same note it appears to lack functionality that run-webkit-tests provides. Can someone please clarify the situation? Thanks, - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
As recently as a week ago, dpranke said that he's planning to continue working on NRWT: https://bugs.webkit.org/show_bug.cgi?id=34984#c3 dpranke just launched OWNERS files for Chromium this morning, so hopefully he'll return to WebKit-land soon! http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/a10ef15234df067d# Adam On Fri, Mar 18, 2011 at 1:51 PM, Mark Rowe mr...@apple.com wrote: On 2011-03-17, at 23:50, Ojan Vafai wrote: * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. Can someone explain the new-run-webkit-tests situation to me? The name suggests it is intended to replace run-webkit-tests. It's been more than a year since it was added and it obviously hasn't replaced run-webkit-tests. As best as I can tell it's not used by any ports unless one happens to invoke it directly. It appears to has new functionality that run-webkit-tests lacks, but on the same note it appears to lack functionality that run-webkit-tests provides. Can someone please clarify the situation? Thanks, - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
NRWT is in use by the Chromium port. At some point I believe the Qt port used it as well. It successfully runs the layout tests for Mac and Win ports as well, last I tried. Obviously it has not replaced ORWT, but I believe that is still the intention. Work on NRWT (by me) stopped about a year ago, when we hit a critical bug in Python' subprocess module, making NRWT hang on the Mac. Others have worked on NWRT re-writes since then (to work around the python bug, among other things). There is a large amount of infrastructure built around NRWT in chromium-land. Ojan's comment contains one example of such infrastructure. I have no timeline for you, as I'm no longer working on NRWT. But others may. -eric On Fri, Mar 18, 2011 at 4:01 PM, Adam Barth aba...@webkit.org wrote: As recently as a week ago, dpranke said that he's planning to continue working on NRWT: https://bugs.webkit.org/show_bug.cgi?id=34984#c3 dpranke just launched OWNERS files for Chromium this morning, so hopefully he'll return to WebKit-land soon! http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/a10ef15234df067d# Adam On Fri, Mar 18, 2011 at 1:51 PM, Mark Rowe mr...@apple.com wrote: On 2011-03-17, at 23:50, Ojan Vafai wrote: * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. Can someone explain the new-run-webkit-tests situation to me? The name suggests it is intended to replace run-webkit-tests. It's been more than a year since it was added and it obviously hasn't replaced run-webkit-tests. As best as I can tell it's not used by any ports unless one happens to invoke it directly. It appears to has new functionality that run-webkit-tests lacks, but on the same note it appears to lack functionality that run-webkit-tests provides. Can someone please clarify the situation? Thanks, - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
In short, what Adam just said :) In long(-er), Your annoyance is quite understandable. I won't go into the reasons for the delay, but the major technical reason has been fixed, finally. These are the issues that I am aware of that remain: * There are GTK bots that run NRWT as well as the Chromium bots * I have been in conversations a bit w/ wms and lforschler to get the apple mac port using it * There are a couple of known minor bugs with the mac port * There are some known minor features missing * There are known issues with the apple win port not working (this is probably the biggest issue keeping things from working, but it shouldn't be too hard to surmount). I hope to make rapid progress on all of these fronts, and pull together all of the others issues into a single fairly easily trackable spot. I would like to be able to either say we're fully cut over or at least give a good update at the meeting in April. -- Dirk On Fri, Mar 18, 2011 at 2:01 PM, Adam Barth aba...@webkit.org wrote: As recently as a week ago, dpranke said that he's planning to continue working on NRWT: https://bugs.webkit.org/show_bug.cgi?id=34984#c3 dpranke just launched OWNERS files for Chromium this morning, so hopefully he'll return to WebKit-land soon! http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/a10ef15234df067d# Adam On Fri, Mar 18, 2011 at 1:51 PM, Mark Rowe mr...@apple.com wrote: On 2011-03-17, at 23:50, Ojan Vafai wrote: * For now, it only works with the bots that use new-run-webkit-tests. If anyone is interested in adding old-run-webkit-tests support, ping me. It should be relatively easy. Can someone explain the new-run-webkit-tests situation to me? The name suggests it is intended to replace run-webkit-tests. It's been more than a year since it was added and it obviously hasn't replaced run-webkit-tests. As best as I can tell it's not used by any ports unless one happens to invoke it directly. It appears to has new functionality that run-webkit-tests lacks, but on the same note it appears to lack functionality that run-webkit-tests provides. Can someone please clarify the situation? Thanks, - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On 2011-03-18, at 14:22, Dirk Pranke wrote:
* There are GTK bots that run NRWT as well as the Chromium bots
Where? None of the bots on build.webkit.org use it as far as I can tell. And
the run-webkit-tests script contains the following:
sub useNewRunWebKitTests()
{
# Change this check to control which platforms use
# new-run-webkit-tests by default.
# Example: return runningOnBuildBot() isLeopard();
# would enable new-run-webkit-tests on only the leopard buildbots.
return 0;
}
- Mark
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On 2011-03-18, at 14:22, Dirk Pranke wrote: In short, what Adam just said :) In long(-er), Your annoyance is quite understandable. Not annoyed, just confused by the existence of two similar-but-subtly-different tools. I won't go into the reasons for the delay, but the major technical reason has been fixed, finally. These are the issues that I am aware of that remain: * There are GTK bots that run NRWT as well as the Chromium bots * I have been in conversations a bit w/ wms and lforschler to get the apple mac port using it * There are a couple of known minor bugs with the mac port Are they tracked in Bugzilla? * There are some known minor features missing Ditto? * There are known issues with the apple win port not working (this is probably the biggest issue keeping things from working, but it shouldn't be too hard to surmount). Ditto? I hope to make rapid progress on all of these fronts, and pull together all of the others issues into a single fairly easily trackable spot. I would like to be able to either say we're fully cut over or at least give a good update at the meeting in April. Thanks for the update. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On Fri, Mar 18, 2011 at 02:25:21PM -0700, Mark Rowe wrote: On 2011-03-18, at 14:22, Dirk Pranke wrote: * There are GTK bots that run NRWT as well as the Chromium bots Where? None of the bots on build.webkit.org use it as far as I can tell. And the run-webkit-tests script contains the following: We added the support for GTK and I use it locally sometimes but we are still not using it in the bots AFAIK. br ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A question about new-run-webkit-tests
On Fri, Mar 18, 2011 at 2:29 PM, Mark Rowe mr...@apple.com wrote: On 2011-03-18, at 14:22, Dirk Pranke wrote: In short, what Adam just said :) In long(-er), Your annoyance is quite understandable. Not annoyed, just confused by the existence of two similar-but-subtly-different tools. Well, I'm annoyed enough for both of us :) Most of the issues are tracked in Bugzilla, but I don't think all of them are. The master tracking bug is: https://bugs.webkit.org/show_bug.cgi?id=34984 which I just added you to :) I will be adding any other issues shortly as I page all of this stuff back in. I thought there was a GTK bot on the waterfall the last time I looked but I'm not seeing it now. It wasn't one of the main builders. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Allow cross-origin XHR requests for non-standard URLs?
Hi. I've been working with the Chromium Embedded Framework (in windows) which gives webkit version 534.20. I am trying to get a custom scheme to work with XHR. By way of background, I first updated the Cef code so that custom schemes can be declared "non-standard", which avoids certain parsing errors. Non-standard schemes include "data", "_javascript_", "file". Webkit has a mechanism for registering standard schemes, so all I needed to do was /not/ register custom schemes that were non-standard. My custom scheme works fine at the beginning of the request. Chromium/Cef successfully calls my scheme handler and my response data is read. But it fails when the DocumentThreadableLoader::DocumentThreadableLoader constructor starts checking for cross-origin security. I was able to get the code to "work" by bypassing the origin tests and simply calling "loadRequest" in that constructor. As a fix, I'd like to propose that non-standard scheme URLs be accessible from any security origin. A patch to SecurityOrigin::canRequest could set DocumentThreadableLoader::m_sameOriginRequest to true if url_util::DoIsStandard returns false. This would use Webkit's existing whitelist mechanism for standard schemes. If necessary, exclusions could be hardcoded if certain non-standard schemes are inappropriate for this policy. Since this could have significant security implications, I wanted to run it by here first. I realize that my use case is stretching XMLHttpRequest well past http, but this would allow using custom schemes with libraries that support AJAX requests, such as JSTree. Curiously enough, I ran into the "rdar" scheme in the code, referencing Apple's internal bug database. Given the current webkit security policy, it would be impossible to access rdar URLs via Ajax. My proposed change would allow it (assuming an appropriate scheme handler is available). FWIW, I'd be happy to figure out and provide a patch. -j -- Joe Andrieu j...@andrieu.net +1 (805) 705-8651 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
