On Mon, Jul 16, 2012 at 2:57 AM, Jochen Eisinger <joc...@chromium.org>wrote:
> > > > On Fri, Jul 13, 2012 at 11:15 PM, Darin Fisher <da...@chromium.org> wrote: > >> >> >> 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. >> > > 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 :) > > Agreed. > > >> >> -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