I created a page with instructions how to use content_shell here: https://sites.google.com/a/chromium.org/dev/developers/testing/webkit-layout-tests/content-shell
At the bottom, I summarized next steps, esp. how we can reuse chromium's test controller for the content shell best -jochen On Mon, Jun 11, 2012 at 1:53 AM, Darin Fisher <[email protected]> wrote: > > > On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger <[email protected]>wrote: > >> >> >> On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa <[email protected]> wrote: >> >>> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger <[email protected]>wrote: >>> >>>> I've implemented initial support for running layout tests using >>>> chromium's content_shell instead of test_shell as the current DRT >>>> implementation does. It's still a very experimental, but might already be >>>> interesting for some of you to try. >>>> >>> >>> This is great! Thanks a lot on working this. >>> >>> 1. Make sure your WebKit is at least at r119852 (see >>>> http://trac.webkit.org/wiki/Chromium for prerequisites) >>>> 2. Apply the attachment from >>>> https://bugs.webkit.org/show_bug.cgi?id=87045 >>>> 3. In Source/WebKit/chromium run gclient sync >>>> 4. build webkit as usual >>>> >>>> E.g. for a debug build on Linux, this should give you >>>> out/Debug/content_shell >>>> >>>> You can now run layout tests like this: >>>> >>>> new-run-webkit-tests --chromium --debug --driver-name=content_shell >>>> --additional-drt-flag=--dump-render-tree LayoutTests/storage/indexeddb/* >>>> >>>> You'll notice that not all tests are passing yet, mainly because not >>>> all (or actually, almost none of the) layoutTestController features are >>>> implemented yet. >>>> >>> >>> Where is layoutTestController implemented? We definitely need to move >>> the implementation of layoutTestController, eventSender, etc... into WebKit >>> repository because we often rename functions, etc... in WebKit. It's >>> unacceptable to require having to modify Chromium code in order to do this >>> refactoring in the future. >>> >> >> It's currently here: >> http://code.google.com/searchframe#OAMlx_jo-ck/src/content/shell/layout_test_controller.js&exact_package=chromium >> >> Per my other thread about sharing IDLs between DumpRenderTree and >>> WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner >>> instead of adding yet another binding code. >>> >>> Another missing feature is producing pixel results. However, I'm >>>> currently concentrating on text results, as I think the biggest benefit is >>>> the ability to run storage tests on the real storage implementation. >>>> >>> >>> That sounds great to me but we definitely need to support pixel results >>> eventually. I'm more than happy to help you on that but that requires the >>> codebase to be moved into WebKit repository. >>> >> >> Here's the basic problem: content_shell depends on content, so moving >> this on the webkit repository would mean that webkit depended on content. >> >> Another solution would be to formalize the test shell API our current >> layout test controller in webkit uses (Tools/DumpRenderTree/chromium), and >> add a method to chromium's webkit support library that returns a webview >> that supports all the hooks required. The webview could then either be >> implemented by test_shell or by content_shell >> >> > ^^^ This second solution seems like it will work well. It will enable the > guts of layoutTestController to remain in the WebKit repository. This is > just a variation of exactly what we do today. You only need to move > creation of WebView to Chromium so that we can eliminate WebViewHost.cpp > (and other "simple" application shell bits). > > -Darin > > > >> best >> -jochen >> >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
