[webkit-dev] Updates on Chromium's content_shell

[Adam Barth]

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

> On Fri, Jul 13, 2012 at 2: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.
>>
>
> In addition to functions that talk with the WebKit API, there are also
> functions that are more about controlling the test harness.  For example,
> dumpAsText and waitUntilDone will need some pathway for communicating with
> the outside world besides WebKit API.
>
> Currently, this information is "pulled" by TestShell.cpp, so maybe we
> don't need the delegate and can just have both DumpRenderTree and
> ContentShell pull this information out of TestRunner.a via some interface.
>

I've created a meta bug to track this work:

https://bugs.webkit.org/show_bug.cgi?id=91308

Adam



>  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/9769c9c9/attachment.html>