[webkit-dev] Updates on Chromium's content_shell

[Darin Fisher]

On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth <abarth at webkit.org> wrote:

> Yeah, EventSender is likely a good place to start.  Here are some more
> details about what I had in mind:
>
> 1) We'll need to create a new target that builds a TestRunner.a (or
> LayoutTestController.a, whatever name is currently in fashion).  This
> target is allowed to depend on WTF, WebKit (via the WebKit API), and
> probably webkit_support.
>
> 2) This target will contain LayoutTestController.cpp, EventSender.cpp, and
> all the other code that's needed to support the objects we inject when
> running LayoutTests.
>
> 3) To move code into this target, we'll need to abstract any dependencies
> on the rest of DumpRenderTree into a delegate interface.  For example,
> EventSender has a #include "TestShell.h", which we'll need to remove.
>  Today, EventSender gets the WebView is by asking m_shell for it.  Instead,
> it will need to ask the delegate.
>
> One of the trickier things in this project will be WebViewHost.
>  TestRunner.a will need some object like that to subclass a bunch of WebKit
> API clients, but the design might need to change a bit.  I haven't studied
> it carefully yet.
>

TestRunner.a could just provide the WebViewClient and WebFrameClient
implementations.  The delegate you mention could just be a createWebView
function.

When Jochen and I discussed this topic before, I suggested just adding
CreateWebView to webkit_support, but as a delegate function seems even
better.  We'd probably like to minimize dependencies on webkit_support
since that is Chromium specific.

-Darin




>
> Once this is done, but DumpRenderTree and ContentShell can link
> in TestRunner.a and implement the delegate.  Hopefully the bulk of the
> interactions will be between TestRunner.a and the WebKit API so that the
> delegate will mostly be able providing the WebView and getting out of the
> way.
>
> Adam
>
>
> On Fri, Jul 13, 2012 at 1:56 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>
>> What about keeping the discussion here, so others that might want to join
>> the effort later can read it up?
>>
>> In general, I agree with your proposal. I guess starting with something
>> small like EventSender might be a good first step.
>>
>> best
>> -jochen
>>
>>
>> On Fri, Jul 13, 2012 at 10:20 PM, Adam Barth <abarth at webkit.org> wrote:
>>
>>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger <jochen at chromium.org>wrote:
>>>
>>>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>>
>>>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger <jochen at chromium.org>wrote:
>>>>>
>>>>>> I wanted to share some updates about content_shell (a multi-processed
>>>>>> version of chromium's test shell): meanwhile, it is possible to generate
>>>>>> pixel results.
>>>>>>
>>>>>> Out of 31431 tests that are executed on chromium-linux, 6234 did not
>>>>>> match the expected results using content_shell, all others passed (80.17%)!
>>>>>>
>>>>>
>>>>> This is a great news! Thanks a lot for working on this effort. Let us
>>>>> know if you needed a help in implementing testRunner methods.
>>>>>
>>>>
>>>> At this point, there are two things I could use help with: in general,
>>>> moving methods to window.internals (and addressing the current shortcomings
>>>> of that approach) helps a lot, as I can just instantiate this object in
>>>> content_shell.
>>>>
>>>> The other thing is to work towards making layoutTestController (of
>>>> chromium's DRT) a library.
>>>>
>>>> Adam mentioned a while ago that he'd be interested with helping with
>>>> the latter as well
>>>>
>>>
>>> Yes.  The idea is to implement LayoutTestController in terms of the
>>> WebKit API and a (hopefully simple) delegate.
>>>  Currently LayoutTestController knows too much about DumpRenderTree.  That
>>> will let us share the implementation of LayoutTestController and avoid
>>> having to maintain yet another copy.
>>>
>>> Upstreaming the chromium-android port is at the top of my priority list,
>>> but I should be able to help out with this work as well.  Should we talk
>>> off-list about how to approach this work?
>>>
>>> Adam
>>>
>>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120713/a43bc831/attachment.html>