On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher <[email protected]> wrote:
> > > On Fri, Jul 13, 2012 at 2:10 PM, Adam Barth <[email protected]> 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 <[email protected]>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 <[email protected]> wrote: >>> >>>> On Fri, Jul 13, 2012 at 1:10 PM, Jochen Eisinger >>>> <[email protected]>wrote: >>>> >>>>> On Fri, Jul 13, 2012 at 7:46 PM, Ryosuke Niwa <[email protected]>wrote: >>>>> >>>>>> On Fri, Jul 13, 2012 at 4:16 AM, Jochen Eisinger <[email protected] >>>>>> > 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 >> [email protected] >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
