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

[Ryosuke Niwa]

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.

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120608/703c1bb9/attachment.html>