[webkit-dev] Running layout tests for the chromium port, using the multi-processing architecture and fully sandboxed

Jochen Eisinger jochen at chromium.org
Fri Jun 8 13:09:03 PDT 2012

On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>>  On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa <rniwa at webkit.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120608/d19bda8e/attachment.html>

More information about the webkit-dev mailing list