<br><br><div class="gmail_quote">On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div class="im">On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger <span dir="ltr"><<a href="mailto:jochen@chromium.org" target="_blank">jochen@chromium.org</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">

On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:</div><div class="im"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div class="gmail_quote"><div>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.</div>




<div><div><br></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.</div>







</blockquote><div><br></div></div><div>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.</div>





</div></blockquote><div><br></div></div><div>Here's the basic problem: content_shell depends on content, so moving this on the webkit repository would mean that webkit depended on content.</div><div><br></div><div>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</div>



</div></div></blockquote><div><br></div><div>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.</div>

</div></blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888">

<div><br></div><div>- Ryosuke</div><div><br></div></font></span></div>
</blockquote></div><br>