On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth <aba...@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 <joc...@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 <aba...@webkit.org> wrote: >> >>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger <joc...@chromium.org>wrote: >>> >>>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >>>> >>>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger >>>>> <joc...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev