On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa <[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: >> >>> 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 >> > > I don't know any architectural details of content_shell so it's hard for > me to comment on this matter, but I don't see a problem in > WebKitChromiumTestRunner (hypothetical name to be consistent with > WebKitTestRunner) depending on content_shell given that WebKitTestRunner > also depends on WebKit2 API. > Today, when somebody adds e.g. a new callback to LayoutTestController, they can just patch DumpRenderTree. If our test runner lived (in large parts) in chromium's repository, such a change would require a patch to chromium. This would either put an additional burden on all WebKit developers, or our test runner constantly gets out of sync. > > - Ryosuke > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
