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
