[webkit-dev] Updates on Chromium's content_shell

[Adam Barth]

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.

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120713/303f5020/attachment.html>