[webkit-dev] Updates on Chromium's content_shell
darin at chromium.org
Fri Jul 13 14:15:25 PDT 2012
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
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.
> 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
> 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.
>> 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
>>>> 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?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev