[webkit-dev] Updates on Chromium's content_shell

[Jochen Eisinger]

On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher <darin at chromium.org> wrote:

>
>
> 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.
>

I think these are two separate issues: one is reusing the bindings for the
test objects. This is what creating a TestRunner library would achieve. The
other is to create the webkit objects without too egregious layering
violations. This is a yet to solve problem :)

-jochen



>
> -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/20120716/0fa343c5/attachment.html>